* [PATCH] netlink: do not proceed if dump's start() errs
From: Jason A. Donenfeld @ 2017-09-27 12:39 UTC (permalink / raw)
To: davem, johannes.berg, netdev, linux-kernel; +Cc: Jason A. Donenfeld, stable
Drivers that use the start method for netlink dumping rely on dumpit not
being called if start fails. For example, ila_xlat.c allocates memory
and assigns it to cb->args[0] in its start() function. It might fail to
do that and return -ENOMEM instead. However, even when returning an
error, dumpit will be called, which, in the example above, quickly
dereferences the memory in cb->args[0], which will OOPS the kernel. This
is but one example of how this goes wrong.
Since start() has always been a function with an int return type, it
therefore makes sense to use it properly, rather than ignoring it. This
patch thus returns early and does not call dumpit() when start() fails.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: stable@vger.kernel.org
---
net/netlink/af_netlink.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 327807731b44..be179876227d 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -2270,8 +2270,11 @@ int __netlink_dump_start(struct sock *ssk, struct sk_buff *skb,
mutex_unlock(nlk->cb_mutex);
- if (cb->start)
- cb->start(cb);
+ if (cb->start) {
+ ret = cb->start(cb);
+ if (ret)
+ return ret;
+ }
ret = netlink_dump(sk);
sock_put(sk);
--
2.14.1
^ permalink raw reply related
* Re: [PATCH v4 net-next 00/12] gtp: Additional feature support - Part I
From: Harald Welte @ 2017-09-27 12:24 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, pablo, aschultz, netdev, rohit
In-Reply-To: <20170927045803.2477-1-tom@quantonium.net>
Hi Tom,
thanks for your updated series!
I'll revie as soon as I a, but that may likely not be before next
week. As indicated before, I'm on a motorbike roadtrip on vacation,
with very limited connectivity and even more limited time for any
technical work. Thanks for your understanding.
--
- Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
^ permalink raw reply
* Re: [PATCH v2] tun: bail out from tun_get_user() if the skb is empty
From: Eric Dumazet @ 2017-09-27 12:42 UTC (permalink / raw)
To: Alexander Potapenko
Cc: davem, edumazet, dvyukov, syzkaller, netdev, linux-kernel
In-Reply-To: <20170927121649.90557-1-glider@google.com>
On Wed, 2017-09-27 at 14:16 +0200, Alexander Potapenko wrote:
> KMSAN (https://github.com/google/kmsan) reported accessing uninitialized
> skb->data[0] in the case the skb is empty (i.e. skb->len is 0):
>
> Signed-off-by: Alexander Potapenko <glider@google.com>
> ---
> v2: free the skb
> ---
> drivers/net/tun.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index 3c9985f29950..0d60fd4ada9e 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -1496,6 +1496,11 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
> switch (tun->flags & TUN_TYPE_MASK) {
> case IFF_TUN:
> if (tun->flags & IFF_NO_PI) {
> + if (!skb->len) {
> + this_cpu_inc(tun->pcpu_stats->rx_dropped);
> + kfree_skb(skb);
> + return -EINVAL;
> + }
> switch (skb->data[0] & 0xf0) {
> case 0x40:
> pi.proto = htons(ETH_P_IP);
Acked-by: Eric Dumazet <edumazet@google.com>
Or something cleaner to avoid copy/paste and focus on proper
skb->data[0] access and meaning.
Thanks.
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 3c9985f299503ea65dad7eb3b47e2ab3bef87800..8ddb840687c1bdb24e4182612abc9e362624c3e9 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1496,11 +1496,13 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
switch (tun->flags & TUN_TYPE_MASK) {
case IFF_TUN:
if (tun->flags & IFF_NO_PI) {
- switch (skb->data[0] & 0xf0) {
- case 0x40:
+ u8 ip_proto = skb->len ? (skb->data[0] >> 4) : 0;
+
+ switch (ip_proto) {
+ case 4:
pi.proto = htons(ETH_P_IP);
break;
- case 0x60:
+ case 6:
pi.proto = htons(ETH_P_IPV6);
break;
default:
^ permalink raw reply related
* Re: [PATCH v2] tun: bail out from tun_get_user() if the skb is empty
From: Eric Dumazet @ 2017-09-27 12:45 UTC (permalink / raw)
To: Alexander Potapenko
Cc: davem, edumazet, dvyukov, syzkaller, netdev, linux-kernel
In-Reply-To: <1506516168.6617.38.camel@edumazet-glaptop3.roam.corp.google.com>
On Wed, 2017-09-27 at 05:42 -0700, Eric Dumazet wrote:
> Or something cleaner to avoid copy/paste and focus on proper
> skb->data[0] access and meaning.
>
> Thanks.
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index 3c9985f299503ea65dad7eb3b47e2ab3bef87800..8ddb840687c1bdb24e4182612abc9e362624c3e9 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -1496,11 +1496,13 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
> switch (tun->flags & TUN_TYPE_MASK) {
> case IFF_TUN:
> if (tun->flags & IFF_NO_PI) {
> - switch (skb->data[0] & 0xf0) {
> - case 0x40:
> + u8 ip_proto = skb->len ? (skb->data[0] >> 4) : 0;
And name this variable ip_version ;)
^ permalink raw reply
* Re: [PATCH] netlink: do not proceed if dump's start() errs
From: Jason A. Donenfeld @ 2017-09-27 12:50 UTC (permalink / raw)
To: David Miller, johannes.berg, Netdev, LKML; +Cc: Jason A. Donenfeld, stable
In-Reply-To: <20170927123915.5779-1-Jason@zx2c4.com>
On Wed, Sep 27, 2017 at 2:39 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> - if (cb->start)
> - cb->start(cb);
> + if (cb->start) {
> + ret = cb->start(cb);
> + if (ret)
I need to sock_put(sk); before returning. I'll fix this for v2, but
will for additional comments in case anybody has some.
> + return ret;
> + }
>
> ret = netlink_dump(sk);
> sock_put(sk);
^ permalink raw reply
* Re: [PATCH v2 net-next 2/2] net/sched: allow flower to match tunnel options
From: Simon Horman @ 2017-09-27 12:52 UTC (permalink / raw)
To: Jiri Pirko
Cc: David Miller, Jiri Pirko, Jamal Hadi Salim, Cong Wang, netdev,
oss-drivers
In-Reply-To: <20170927110822.GD1944@nanopsycho.orion>
On Wed, Sep 27, 2017 at 01:08:22PM +0200, Jiri Pirko wrote:
> Wed, Sep 27, 2017 at 11:27:33AM CEST, simon.horman@netronome.com wrote:
> >On Wed, Sep 27, 2017 at 11:10:05AM +0200, Jiri Pirko wrote:
> >> Wed, Sep 27, 2017 at 10:16:34AM CEST, simon.horman@netronome.com wrote:
...
> >> > enum flow_dissector_key_id {
> >> > FLOW_DISSECTOR_KEY_CONTROL, /* struct flow_dissector_key_control */
> >> > FLOW_DISSECTOR_KEY_BASIC, /* struct flow_dissector_key_basic */
> >> >@@ -205,6 +217,7 @@ enum flow_dissector_key_id {
> >> > FLOW_DISSECTOR_KEY_MPLS, /* struct flow_dissector_key_mpls */
> >> > FLOW_DISSECTOR_KEY_TCP, /* struct flow_dissector_key_tcp */
> >> > FLOW_DISSECTOR_KEY_IP, /* struct flow_dissector_key_ip */
> >> >+ FLOW_DISSECTOR_KEY_ENC_OPTS, /* struct flow_dissector_key_enc_opts */
> >>
> >> I don't see the actual dissection implementation. Where is it?
> >> Did you test the patchset?
> >
> >Yes, I did test it. But it is also possible something went astray along the
> >way and I will retest.
> >
> >I think that the code you are looking for is in
> >fl_classify() in this patch.
>
> The dissection should be done in the flow_dissector. That's the whole
> point in having it generic. You should move it there.
Coming back to this after lunch, I believe what I have done in this patch
is consistent with handling of other enc fields, which are set in
fl_classify() rather than the dissector. In particular the ip_tunnel_info,
which is used by this patch, is already used in fl_classify().
Without this patch I see:
static int fl_classify(struct sk_buff *skb, const struct tcf_proto *tp,
struct tcf_result *res)
{
...
struct ip_tunnel_info *info;
...
info = skb_tunnel_info(skb);
if (info) {
struct ip_tunnel_key *key = &info->key;
switch (ip_tunnel_info_af(info)) {
case AF_INET:
skb_key.enc_control.addr_type =
FLOW_DISSECTOR_KEY_IPV4_ADDRS;
skb_key.enc_ipv4.src = key->u.ipv4.src;
skb_key.enc_ipv4.dst = key->u.ipv4.dst;
break;
case AF_INET6:
skb_key.enc_control.addr_type =
FLOW_DISSECTOR_KEY_IPV6_ADDRS;
skb_key.enc_ipv6.src = key->u.ipv6.src;
skb_key.enc_ipv6.dst = key->u.ipv6.dst;
break;
}
skb_key.enc_key_id.keyid = tunnel_id_to_key32(key->tun_id);
skb_key.enc_tp.src = key->tp_src;
skb_key.enc_tp.dst = key->tp_dst;
}
...
}
This patch adds the following inside the if() clause above:
if (info->options_len) {
skb_key.enc_opts.len = info->options_len;
ip_tunnel_info_opts_get(skb_key.enc_opts.data, info);
}
^ permalink raw reply
* Re: tc H/W offload issue with vxlan tunnels [was: nfp: flower vxlan tunnel offload]
From: Jiri Pirko @ 2017-09-27 12:55 UTC (permalink / raw)
To: Paolo Abeni
Cc: Or Gerlitz, Jiri Benc, Simon Horman, David Miller, Jakub Kicinski,
Linux Netdev List, oss-drivers, John Hurley, Paul Blakey,
Jiri Pirko, Roi Dayan
In-Reply-To: <1506515496.6840.6.camel@redhat.com>
Wed, Sep 27, 2017 at 02:31:36PM CEST, pabeni@redhat.com wrote:
>On Wed, 2017-09-27 at 13:11 +0200, Jiri Pirko wrote:
>> Wed, Sep 27, 2017 at 11:46:58AM CEST, pabeni@redhat.com wrote:
>> > On Wed, 2017-09-27 at 11:17 +0200, Jiri Pirko wrote:
>> > > Wed, Sep 27, 2017 at 10:29:35AM CEST, pabeni@redhat.com wrote:
>> > > > So it looks like the H/W offload hook will still be called with the
>> > > > same arguments in both case, and 'bad' rule will still be pushed to the
>> > > > H/W as the driver itself has no way to distinct between the two
>> > > > scenarios.
>> > >
>> > > Why "bad"?
>> >
>> > Such rule is coped differently by the SW and the HW data path.
>> >
>> > a rule like:
>> >
>> > tc filter add dev eth0 protocol ip parent ffff: flower \
>> > enc_key_id 102 enc_dst_port 4789 src_ip 3.4.5.6 skip_hw \
>> > action action mirred redirect eth0_vf_1
>> >
>> > will match 0 packets, while:
>> >
>> > tc filter add dev eth0 protocol ip parent ffff: flower \
>> > enc_key_id 102 enc_dst_port 4789 src_ip 3.4.5.6 skip_sw \
>> > action action mirred redirect eth0_vf_1
>> >
>> > [just flipped 'skip_sw' and 'skip_hw' ]
>> > will match the vxlan-tunneled packets. I understand that one of the
>> > design goal for the h/w offload path is being consistent with the sw
>> > one, but that does not hold in the above scenario.
>>
>> Sure, the consistency is important. Howcome "skip_hw" won't match and
>> "skip_sw" will match? What's different?
>
>For the SW datapath, we need a metadata based/lwt tunnel to collect the
>tunnel information. eth0 is not a such device and does not provide the
>metadata. Any match on tunnel based field will fail - correctly.
So where do you attach the tc filter instead of eth0? vxlan0?
>
>When the HW datapath is used, the underlaying NIC is programmed exactly
>as done when we replace eth0 with vxlan0. The programmed flow matches
>vxlan encapsulated traffic.
Ok, so we should unify the behaviour with sw path and don't allow such
mathing in hw.
>
>Cheers,
>
>Paolo
^ permalink raw reply
* Re: [PATCH v2 net-next 2/2] net/sched: allow flower to match tunnel options
From: Jiri Pirko @ 2017-09-27 12:56 UTC (permalink / raw)
To: Simon Horman
Cc: David Miller, Jiri Pirko, Jamal Hadi Salim, Cong Wang, netdev,
oss-drivers
In-Reply-To: <20170927125205.GA30000@vergenet.net>
Wed, Sep 27, 2017 at 02:52:06PM CEST, simon.horman@netronome.com wrote:
>On Wed, Sep 27, 2017 at 01:08:22PM +0200, Jiri Pirko wrote:
>> Wed, Sep 27, 2017 at 11:27:33AM CEST, simon.horman@netronome.com wrote:
>> >On Wed, Sep 27, 2017 at 11:10:05AM +0200, Jiri Pirko wrote:
>> >> Wed, Sep 27, 2017 at 10:16:34AM CEST, simon.horman@netronome.com wrote:
>
>...
>
>> >> > enum flow_dissector_key_id {
>> >> > FLOW_DISSECTOR_KEY_CONTROL, /* struct flow_dissector_key_control */
>> >> > FLOW_DISSECTOR_KEY_BASIC, /* struct flow_dissector_key_basic */
>> >> >@@ -205,6 +217,7 @@ enum flow_dissector_key_id {
>> >> > FLOW_DISSECTOR_KEY_MPLS, /* struct flow_dissector_key_mpls */
>> >> > FLOW_DISSECTOR_KEY_TCP, /* struct flow_dissector_key_tcp */
>> >> > FLOW_DISSECTOR_KEY_IP, /* struct flow_dissector_key_ip */
>> >> >+ FLOW_DISSECTOR_KEY_ENC_OPTS, /* struct flow_dissector_key_enc_opts */
>> >>
>> >> I don't see the actual dissection implementation. Where is it?
>> >> Did you test the patchset?
>> >
>> >Yes, I did test it. But it is also possible something went astray along the
>> >way and I will retest.
>> >
>> >I think that the code you are looking for is in
>> >fl_classify() in this patch.
>>
>> The dissection should be done in the flow_dissector. That's the whole
>> point in having it generic. You should move it there.
>
>Coming back to this after lunch, I believe what I have done in this patch
>is consistent with handling of other enc fields, which are set in
>fl_classify() rather than the dissector. In particular the ip_tunnel_info,
>which is used by this patch, is already used in fl_classify().
That means the current code is wrong. The dissection should be done in
flow_dissector, not in fl_classify.
>
>Without this patch I see:
>
>
>static int fl_classify(struct sk_buff *skb, const struct tcf_proto *tp,
> struct tcf_result *res)
>{
> ...
> struct ip_tunnel_info *info;
>
> ...
>
> info = skb_tunnel_info(skb);
> if (info) {
> struct ip_tunnel_key *key = &info->key;
>
> switch (ip_tunnel_info_af(info)) {
> case AF_INET:
> skb_key.enc_control.addr_type =
> FLOW_DISSECTOR_KEY_IPV4_ADDRS;
> skb_key.enc_ipv4.src = key->u.ipv4.src;
> skb_key.enc_ipv4.dst = key->u.ipv4.dst;
> break;
> case AF_INET6:
> skb_key.enc_control.addr_type =
> FLOW_DISSECTOR_KEY_IPV6_ADDRS;
> skb_key.enc_ipv6.src = key->u.ipv6.src;
> skb_key.enc_ipv6.dst = key->u.ipv6.dst;
> break;
> }
>
> skb_key.enc_key_id.keyid = tunnel_id_to_key32(key->tun_id);
> skb_key.enc_tp.src = key->tp_src;
> skb_key.enc_tp.dst = key->tp_dst;
> }
>
> ...
>}
>
>This patch adds the following inside the if() clause above:
>
> if (info->options_len) {
> skb_key.enc_opts.len = info->options_len;
> ip_tunnel_info_opts_get(skb_key.enc_opts.data, info);
> }
>
>
^ permalink raw reply
* Re: [PATCH v2] tun: bail out from tun_get_user() if the skb is empty
From: Alexander Potapenko @ 2017-09-27 12:58 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, Eric Dumazet, Dmitriy Vyukov, syzkaller, Networking,
LKML
In-Reply-To: <1506516344.6617.39.camel@edumazet-glaptop3.roam.corp.google.com>
On Wed, Sep 27, 2017 at 2:45 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Wed, 2017-09-27 at 05:42 -0700, Eric Dumazet wrote:
>
>> Or something cleaner to avoid copy/paste and focus on proper
>> skb->data[0] access and meaning.
By the way I'm wondering if this is the only place where skb->data is
being accessed.
Isn't eth_type_trans() under IFF_TAP also touching it? Then we need to
check the size earlier.
>> Thanks.
>>
>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>> index 3c9985f299503ea65dad7eb3b47e2ab3bef87800..8ddb840687c1bdb24e4182612abc9e362624c3e9 100644
>> --- a/drivers/net/tun.c
>> +++ b/drivers/net/tun.c
>> @@ -1496,11 +1496,13 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
>> switch (tun->flags & TUN_TYPE_MASK) {
>> case IFF_TUN:
>> if (tun->flags & IFF_NO_PI) {
>> - switch (skb->data[0] & 0xf0) {
>> - case 0x40:
>> + u8 ip_proto = skb->len ? (skb->data[0] >> 4) : 0;
>
> And name this variable ip_version ;)
>
>
>
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
^ permalink raw reply
* Re: [PATCH] netlink: do not proceed if dump's start() errs
From: Johannes Berg @ 2017-09-27 13:05 UTC (permalink / raw)
To: Jason A. Donenfeld, David Miller, Netdev, LKML; +Cc: stable
In-Reply-To: <CAHmME9pUWenvkMCNkAHa6K71UDdETvriMr52sKPL38q19M3RVw@mail.gmail.com>
On Wed, 2017-09-27 at 14:50 +0200, Jason A. Donenfeld wrote:
> On Wed, Sep 27, 2017 at 2:39 PM, Jason A. Donenfeld <Jason@zx2c4.com>
> wrote:
> > - if (cb->start)
> > - cb->start(cb);
> > + if (cb->start) {
> > + ret = cb->start(cb);
> > + if (ret)
>
> I need to sock_put(sk); before returning. I'll fix this for v2, but
> will for additional comments in case anybody has some.
I guess you could change it to
if (cb->start)
ret = cb->start(cb);
if (!ret)
ret = netlink_dump(sk);
johannes
^ permalink raw reply
* Re: [PATCH] netlink: do not proceed if dump's start() errs
From: Jason A. Donenfeld @ 2017-09-27 13:06 UTC (permalink / raw)
To: Johannes Berg; +Cc: David Miller, Netdev, LKML, stable
In-Reply-To: <1506517514.2108.2.camel@sipsolutions.net>
On Wed, Sep 27, 2017 at 3:05 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> I guess you could change it to
>
> if (cb->start)
> ret = cb->start(cb);
> if (!ret)
> ret = netlink_dump(sk);
Very clean. I'll do it like that. I'll wait a bit longer before
submitting v2, but beyond that, seems sane to you?
Jason
^ permalink raw reply
* Re: [PATCH net v2] net: dsa: mv88e6xxx: lock mutex when freeing IRQs
From: Andrew Lunn @ 2017-09-27 13:07 UTC (permalink / raw)
To: David Laight
Cc: 'Vivien Didelot', netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, kernel@savoirfairelinux.com,
David S. Miller, Florian Fainelli
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DD00822B6@AcuExch.aculab.com>
On Wed, Sep 27, 2017 at 09:06:01AM +0000, David Laight wrote:
> From: Vivien Didelot
> > Sent: 26 September 2017 19:57
> > mv88e6xxx_g2_irq_free locks the registers mutex, but not
> > mv88e6xxx_g1_irq_free, which results in a stack trace from
> > assert_reg_lock when unloading the mv88e6xxx module. Fix this.
> >
> > Fixes: 3460a5770ce9 ("net: dsa: mv88e6xxx: Mask g1 interrupts and free interrupt")
> > Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
> > ---
> > drivers/net/dsa/mv88e6xxx/chip.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
> > index c6678aa9b4ef..e7ff7483d2fb 100644
> > --- a/drivers/net/dsa/mv88e6xxx/chip.c
> > +++ b/drivers/net/dsa/mv88e6xxx/chip.c
> > @@ -3947,7 +3947,9 @@ static void mv88e6xxx_remove(struct mdio_device *mdiodev)
> > if (chip->irq > 0) {
> > if (chip->info->g2_irqs > 0)
> > mv88e6xxx_g2_irq_free(chip);
> > + mutex_lock(&chip->reg_lock);
> > mv88e6xxx_g1_irq_free(chip);
> > + mutex_unlock(&chip->reg_lock);
>
> Isn't the irq_free code likely to have to sleep waiting for any
> ISR to complete??
Hi David
Possibly. But this is a mutex, not a spinlock. So sleeping is O.K.
Or am i missing something?
Andrew
^ permalink raw reply
* [PATCH net-next] net: bridge: add per-port group_fwd_mask with less restrictions
From: Nikolay Aleksandrov @ 2017-09-27 13:12 UTC (permalink / raw)
To: netdev; +Cc: roopa, bridge, stephen, Nikolay Aleksandrov
We need to be able to transparently forward most link-local frames via
tunnels (e.g. vxlan, qinq). Currently the bridge's group_fwd_mask has a
mask which restricts the forwarding of STP and LACP, but we need to be able
to forward these over tunnels and control that forwarding on a per-port
basis thus add a new per-port group_fwd_mask option which only disallows
mac pause frames to be forwarded (they're always dropped anyway).
The patch does not change the current default situation - all of the others
are still restricted unless configured for forwarding.
We have successfully tested this patch with LACP and STP forwarding over
VxLAN and qinq tunnels.
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
note: I left the permissions like this to be consistent with all the other
port options.
include/uapi/linux/if_link.h | 1 +
net/bridge/br_input.c | 1 +
net/bridge/br_netlink.c | 14 +++++++++++++-
net/bridge/br_private.h | 10 +++++++++-
net/bridge/br_sysfs_if.c | 18 ++++++++++++++++++
5 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
index 8d062c58d5cb..ea87bd708ee9 100644
--- a/include/uapi/linux/if_link.h
+++ b/include/uapi/linux/if_link.h
@@ -325,6 +325,7 @@ enum {
IFLA_BRPORT_MCAST_TO_UCAST,
IFLA_BRPORT_VLAN_TUNNEL,
IFLA_BRPORT_BCAST_FLOOD,
+ IFLA_BRPORT_GROUP_FWD_MASK,
__IFLA_BRPORT_MAX
};
#define IFLA_BRPORT_MAX (__IFLA_BRPORT_MAX - 1)
diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
index 7637f58c1226..7cb613776b31 100644
--- a/net/bridge/br_input.c
+++ b/net/bridge/br_input.c
@@ -289,6 +289,7 @@ rx_handler_result_t br_handle_frame(struct sk_buff **pskb)
*
* Others reserved for future standardization
*/
+ fwd_mask |= p->group_fwd_mask;
switch (dest[5]) {
case 0x00: /* Bridge Group Address */
/* If STP is turned off,
diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
index 3bc890716c89..dea88a255d26 100644
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
@@ -152,6 +152,7 @@ static inline size_t br_port_info_size(void)
#ifdef CONFIG_BRIDGE_IGMP_SNOOPING
+ nla_total_size(sizeof(u8)) /* IFLA_BRPORT_MULTICAST_ROUTER */
#endif
+ + nla_total_size(sizeof(u16)) /* IFLA_BRPORT_GROUP_FWD_MASK */
+ 0;
}
@@ -208,7 +209,8 @@ static int br_port_fill_attrs(struct sk_buff *skb,
p->topology_change_ack) ||
nla_put_u8(skb, IFLA_BRPORT_CONFIG_PENDING, p->config_pending) ||
nla_put_u8(skb, IFLA_BRPORT_VLAN_TUNNEL, !!(p->flags &
- BR_VLAN_TUNNEL)))
+ BR_VLAN_TUNNEL)) ||
+ nla_put_u16(skb, IFLA_BRPORT_GROUP_FWD_MASK, p->group_fwd_mask))
return -EMSGSIZE;
timerval = br_timer_value(&p->message_age_timer);
@@ -637,6 +639,7 @@ static const struct nla_policy br_port_policy[IFLA_BRPORT_MAX + 1] = {
[IFLA_BRPORT_MCAST_TO_UCAST] = { .type = NLA_U8 },
[IFLA_BRPORT_MCAST_FLOOD] = { .type = NLA_U8 },
[IFLA_BRPORT_BCAST_FLOOD] = { .type = NLA_U8 },
+ [IFLA_BRPORT_GROUP_FWD_MASK] = { .type = NLA_U16 },
};
/* Change the state of the port and notify spanning tree */
@@ -773,6 +776,15 @@ static int br_setport(struct net_bridge_port *p, struct nlattr *tb[])
return err;
}
#endif
+
+ if (tb[IFLA_BRPORT_GROUP_FWD_MASK]) {
+ u16 fwd_mask = nla_get_u16(tb[IFLA_BRPORT_GROUP_FWD_MASK]);
+
+ if (fwd_mask & BR_GROUPFWD_MACPAUSE)
+ return -EINVAL;
+ p->group_fwd_mask = fwd_mask;
+ }
+
br_port_flags_change(p, old_flags ^ p->flags);
return 0;
}
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index e870cfc85b14..020c709a017f 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -36,7 +36,14 @@
/* Control of forwarding link local multicast */
#define BR_GROUPFWD_DEFAULT 0
/* Don't allow forwarding of control protocols like STP, MAC PAUSE and LACP */
-#define BR_GROUPFWD_RESTRICTED 0x0007u
+enum {
+ BR_GROUPFWD_STP = BIT(0),
+ BR_GROUPFWD_MACPAUSE = BIT(1),
+ BR_GROUPFWD_LACP = BIT(2),
+};
+
+#define BR_GROUPFWD_RESTRICTED (BR_GROUPFWD_STP | BR_GROUPFWD_MACPAUSE | \
+ BR_GROUPFWD_LACP)
/* The Nearest Customer Bridge Group Address, 01-80-C2-00-00-[00,0B,0C,0D,0F] */
#define BR_GROUPFWD_8021AD 0xB801u
@@ -268,6 +275,7 @@ struct net_bridge_port {
#ifdef CONFIG_NET_SWITCHDEV
int offload_fwd_mark;
#endif
+ u16 group_fwd_mask;
};
#define br_auto_port(p) ((p)->flags & BR_AUTO_MASK)
diff --git a/net/bridge/br_sysfs_if.c b/net/bridge/br_sysfs_if.c
index 5d5d413a6cf8..9110d5e56085 100644
--- a/net/bridge/br_sysfs_if.c
+++ b/net/bridge/br_sysfs_if.c
@@ -165,6 +165,23 @@ static int store_flush(struct net_bridge_port *p, unsigned long v)
}
static BRPORT_ATTR(flush, S_IWUSR, NULL, store_flush);
+static ssize_t show_group_fwd_mask(struct net_bridge_port *p, char *buf)
+{
+ return sprintf(buf, "%#x\n", p->group_fwd_mask);
+}
+
+static int store_group_fwd_mask(struct net_bridge_port *p,
+ unsigned long v)
+{
+ if (v & BR_GROUPFWD_MACPAUSE)
+ return -EINVAL;
+ p->group_fwd_mask = v;
+
+ return 0;
+}
+static BRPORT_ATTR(group_fwd_mask, S_IRUGO | S_IWUSR, show_group_fwd_mask,
+ store_group_fwd_mask);
+
BRPORT_ATTR_FLAG(hairpin_mode, BR_HAIRPIN_MODE);
BRPORT_ATTR_FLAG(bpdu_guard, BR_BPDU_GUARD);
BRPORT_ATTR_FLAG(root_block, BR_ROOT_BLOCK);
@@ -223,6 +240,7 @@ static const struct brport_attribute *brport_attrs[] = {
&brport_attr_proxyarp_wifi,
&brport_attr_multicast_flood,
&brport_attr_broadcast_flood,
+ &brport_attr_group_fwd_mask,
NULL
};
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v2] tun: bail out from tun_get_user() if the skb is empty
From: Eric Dumazet @ 2017-09-27 13:26 UTC (permalink / raw)
To: Alexander Potapenko
Cc: Eric Dumazet, David Miller, Dmitriy Vyukov, syzkaller, Networking,
LKML
In-Reply-To: <CAG_fn=U8Yjxo2LDC3WenGQUOQZwftd3-j4V8Zz5vSMWobx7Bdw@mail.gmail.com>
On Wed, Sep 27, 2017 at 5:58 AM, Alexander Potapenko <glider@google.com> wrote:
> On Wed, Sep 27, 2017 at 2:45 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> On Wed, 2017-09-27 at 05:42 -0700, Eric Dumazet wrote:
>>
>>> Or something cleaner to avoid copy/paste and focus on proper
>>> skb->data[0] access and meaning.
> By the way I'm wondering if this is the only place where skb->data is
> being accessed.
> Isn't eth_type_trans() under IFF_TAP also touching it? Then we need to
> check the size earlier.
It is already checked.
^ permalink raw reply
* Re: [PATCH v4 4/9] em28xx: fix em28xx_dvb_init for KASAN
From: Arnd Bergmann @ 2017-09-27 13:26 UTC (permalink / raw)
To: Andrey Ryabinin
Cc: David Laight, Mauro Carvalho Chehab, Jiri Pirko, Arend van Spriel,
Kalle Valo, David S. Miller, Alexander Potapenko, Dmitry Vyukov,
Masahiro Yamada, Michal Marek, Andrew Morton, Kees Cook,
Geert Uytterhoeven, Greg Kroah-Hartman,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, "linux-wireless@v
In-Reply-To: <e7e6418e-4340-5057-aa17-800082aca5fb@virtuozzo.com>
On Tue, Sep 26, 2017 at 9:49 AM, Andrey Ryabinin
<aryabinin@virtuozzo.com> wrote:
>
>
> On 09/26/2017 09:47 AM, Arnd Bergmann wrote:
>> On Mon, Sep 25, 2017 at 11:32 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> + ret = __builtin_strlen(q);
>
>
> I think this is not correct. Fortified strlen called here on purpose. If sizeof q is known at compile time
> and 'q' contains not-null fortified strlen() will panic.
Ok, got it.
>> if (size) {
>> size_t len = (ret >= size) ? size - 1 : ret;
>> if (__builtin_constant_p(len) && len >= p_size)
>>
>> The problem is apparently that the fortified strlcpy calls the fortified strlen,
>> which in turn calls strnlen and that ends up calling the extern '__real_strnlen'
>> that gcc cannot reduce to a constant expression for a constant input.
>
>
> Per my observation, it's the code like this:
> if ()
> fortify_panic(__func__);
>
>
> somehow prevent gcc to merge several "struct i2c_board_info info;" into one stack slot.
> With the hack bellow, stack usage reduced to ~1,6K:
1.6k is also what I see with my patch, or any other approach I tried
that changes
string.h. With the split up em28xx_dvb_init() function (and without
changes to string.h),
I got down to a few hundred bytes for the largest handler.
> ---
> include/linux/string.h | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/include/linux/string.h b/include/linux/string.h
> index 54d21783e18d..9a96ff3ebf94 100644
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -261,8 +261,6 @@ __FORTIFY_INLINE __kernel_size_t strlen(const char *p)
> if (p_size == (size_t)-1)
> return __builtin_strlen(p);
> ret = strnlen(p, p_size);
> - if (p_size <= ret)
> - fortify_panic(__func__);
> return ret;
> }
>
> @@ -271,8 +269,6 @@ __FORTIFY_INLINE __kernel_size_t strnlen(const char *p, __kernel_size_t maxlen)
> {
> size_t p_size = __builtin_object_size(p, 0);
> __kernel_size_t ret = __real_strnlen(p, maxlen < p_size ? maxlen : p_size);
> - if (p_size <= ret && maxlen != ret)
> - fortify_panic(__func__);
> return ret;
I've reduced it further to this change:
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -227,7 +227,7 @@ static inline const char *kbasename(const char *path)
#define __FORTIFY_INLINE extern __always_inline __attribute__((gnu_inline))
#define __RENAME(x) __asm__(#x)
-void fortify_panic(const char *name) __noreturn __cold;
+void fortify_panic(const char *name) __cold;
void __read_overflow(void) __compiletime_error("detected read beyond
size of object passed as 1st parameter");
void __read_overflow2(void) __compiletime_error("detected read beyond
size of object passed as 2nd parameter");
void __read_overflow3(void) __compiletime_error("detected read beyond
size of object passed as 3rd parameter");
I don't immediately see why the __noreturn changes the behavior here, any idea?
>> Not sure if that change is the best fix, but it seems to address the problem in
>> this driver and probably leads to better code in other places as well.
>>
>
> Probably it would be better to solve this on the strlcpy side, but I haven't found the way to do this right.
> Alternative solutions:
>
> - use memcpy() instead of strlcpy(). All source strings are smaller than I2C_NAME_SIZE, so we could
> do something like this - memcpy(info.type, "si2168", sizeof("si2168"));
> Also this should be faster.
This would be very similar to the patch I posted at the start of this
thread to use strncpy(), right?
I was hoping that changing strlcpy() here could also improve other
users that might run into
the same situation, but stay below the 2048-byte stack frame limit.
> - Move code under different "case:" in the switch(dev->model) to the separate function should help as well.
> But it might be harder to backport into stables.
Agreed, I posted this in earlier versions of the patch series, see
https://patchwork.kernel.org/patch/9601025/
The new patch was a result of me trying to come up with a less
invasive version to
make it easier to backport, since I would like to backport the last
patch in the series
that depends on all the earlier ones.
Arnd
^ permalink raw reply
* Re: [PATCH net-next 2/6] bpf: add meta pointer for direct access
From: John Fastabend @ 2017-09-27 13:35 UTC (permalink / raw)
To: Jesper Dangaard Brouer, Daniel Borkmann
Cc: davem, alexei.starovoitov, peter.waskiewicz.jr, jakub.kicinski,
netdev, Andy Gospodarek
In-Reply-To: <20170927112604.1284f536@redhat.com>
On 09/27/2017 02:26 AM, Jesper Dangaard Brouer wrote:
> On Tue, 26 Sep 2017 21:58:53 +0200
> Daniel Borkmann <daniel@iogearbox.net> wrote:
>
>> On 09/26/2017 09:13 PM, Jesper Dangaard Brouer wrote:
>> [...]
>>> I'm currently implementing a cpumap type, that transfers raw XDP frames
>>> to another CPU, and the SKB is allocated on the remote CPU. (It
>>> actually works extremely well).
>>
>> Meaning you let all the XDP_PASS packets get processed on a
>> different CPU, so you can reserve the whole CPU just for
>> prefiltering, right?
>
> Yes, exactly. Except I use the XDP_REDIRECT action to steer packets.
> The trick is using the map-flush point, to transfer packets in bulk to
> the remote CPU (single call IPC is too slow), but at the same time
> flush single packets if NAPI didn't see a bulk.
>
>> Do you have some numbers to share at this point, just curious when
>> you mention it works extremely well.
>
> Sure... I've done a lot of benchmarking on this patchset ;-)
> I have a benchmark program called xdp_redirect_cpu [1][2], that collect
> stats via tracepoints (atm I'm limiting bulking 8 packets, and have
> tracepoints at bulk spots, to amortize tracepoint cost 25ns/8=3.125ns)
>
> [1] https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/samples/bpf/xdp_redirect_cpu_kern.c
> [2] https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/samples/bpf/xdp_redirect_cpu_user.c
>
> Here I'm installing a DDoS program that drops UDP port 9 (pktgen
> packets) on RX CPU=0. I'm forcing my netperf to hit the same CPU, that
> the 11.9Mpps DDoS attack is hitting.
>
> Running XDP/eBPF prog_num:4
> XDP-cpumap CPU:to pps drop-pps extra-info
> XDP-RX 0 12,030,471 11,966,982 0
> XDP-RX total 12,030,471 11,966,982
> cpumap-enqueue 0:2 63,488 0 0
> cpumap-enqueue sum:2 63,488 0 0
> cpumap_kthread 2 63,488 0 3 time_exceed
> cpumap_kthread total 63,488 0 0
> redirect_err total 0 0
>
> $ netperf -H 172.16.0.2 -t TCP_CRR -l 10 -D1 -T5,5 -- -r 1024,1024
> Local /Remote
> Socket Size Request Resp. Elapsed Trans.
> Send Recv Size Size Time Rate
> bytes Bytes bytes bytes secs. per sec
>
> 16384 87380 1024 1024 10.00 12735.97
> 16384 87380
>
> The netperf TCP_CRR performance is the same, without XDP loaded.
>
Just curious could you also try this with RPS enabled (or does this have
RPS enabled). RPS should effectively do the same thing but higher in the
stack. I'm curious what the delta would be. Might be another interesting
case and fairly easy to setup if you already have the above scripts.
Thanks,
John
[...]
^ permalink raw reply
* Re: [PATCH v2 net-next 2/2] net/sched: allow flower to match tunnel options
From: Simon Horman @ 2017-09-27 13:37 UTC (permalink / raw)
To: Jiri Pirko
Cc: David Miller, Jiri Pirko, Jamal Hadi Salim, Cong Wang, netdev,
oss-drivers
In-Reply-To: <20170927125603.GH1944@nanopsycho.orion>
On Wed, Sep 27, 2017 at 02:56:03PM +0200, Jiri Pirko wrote:
> Wed, Sep 27, 2017 at 02:52:06PM CEST, simon.horman@netronome.com wrote:
> >On Wed, Sep 27, 2017 at 01:08:22PM +0200, Jiri Pirko wrote:
> >> Wed, Sep 27, 2017 at 11:27:33AM CEST, simon.horman@netronome.com wrote:
> >> >On Wed, Sep 27, 2017 at 11:10:05AM +0200, Jiri Pirko wrote:
> >> >> Wed, Sep 27, 2017 at 10:16:34AM CEST, simon.horman@netronome.com wrote:
> >
> >...
> >
> >> >> > enum flow_dissector_key_id {
> >> >> > FLOW_DISSECTOR_KEY_CONTROL, /* struct flow_dissector_key_control */
> >> >> > FLOW_DISSECTOR_KEY_BASIC, /* struct flow_dissector_key_basic */
> >> >> >@@ -205,6 +217,7 @@ enum flow_dissector_key_id {
> >> >> > FLOW_DISSECTOR_KEY_MPLS, /* struct flow_dissector_key_mpls */
> >> >> > FLOW_DISSECTOR_KEY_TCP, /* struct flow_dissector_key_tcp */
> >> >> > FLOW_DISSECTOR_KEY_IP, /* struct flow_dissector_key_ip */
> >> >> >+ FLOW_DISSECTOR_KEY_ENC_OPTS, /* struct flow_dissector_key_enc_opts */
> >> >>
> >> >> I don't see the actual dissection implementation. Where is it?
> >> >> Did you test the patchset?
> >> >
> >> >Yes, I did test it. But it is also possible something went astray along the
> >> >way and I will retest.
> >> >
> >> >I think that the code you are looking for is in
> >> >fl_classify() in this patch.
> >>
> >> The dissection should be done in the flow_dissector. That's the whole
> >> point in having it generic. You should move it there.
> >
> >Coming back to this after lunch, I believe what I have done in this patch
> >is consistent with handling of other enc fields, which are set in
> >fl_classify() rather than the dissector. In particular the ip_tunnel_info,
> >which is used by this patch, is already used in fl_classify().
>
> That means the current code is wrong. The dissection should be done in
> flow_dissector, not in fl_classify.
Would an better approach be to move the fl_classify() below into, say,
skb_flow_dissect_tunnel_info() and call that from fl_classify().
The reason I suggest this rather than moving the code into
__skb_flow_dissect() is that currently flower assumes that tunnel_info
is used if present. While I assume other users of () assume tunnel_info
is not used even if present.
> >Without this patch I see:
> >
> >
> >static int fl_classify(struct sk_buff *skb, const struct tcf_proto *tp,
> > struct tcf_result *res)
> >{
> > ...
> > struct ip_tunnel_info *info;
> >
> > ...
> >
> > info = skb_tunnel_info(skb);
> > if (info) {
> > struct ip_tunnel_key *key = &info->key;
> >
> > switch (ip_tunnel_info_af(info)) {
> > case AF_INET:
> > skb_key.enc_control.addr_type =
> > FLOW_DISSECTOR_KEY_IPV4_ADDRS;
> > skb_key.enc_ipv4.src = key->u.ipv4.src;
> > skb_key.enc_ipv4.dst = key->u.ipv4.dst;
> > break;
> > case AF_INET6:
> > skb_key.enc_control.addr_type =
> > FLOW_DISSECTOR_KEY_IPV6_ADDRS;
> > skb_key.enc_ipv6.src = key->u.ipv6.src;
> > skb_key.enc_ipv6.dst = key->u.ipv6.dst;
> > break;
> > }
> >
> > skb_key.enc_key_id.keyid = tunnel_id_to_key32(key->tun_id);
> > skb_key.enc_tp.src = key->tp_src;
> > skb_key.enc_tp.dst = key->tp_dst;
> > }
> >
> > ...
> >}
> >
> >This patch adds the following inside the if() clause above:
> >
> > if (info->options_len) {
> > skb_key.enc_opts.len = info->options_len;
> > ip_tunnel_info_opts_get(skb_key.enc_opts.data, info);
> > }
> >
> >
^ permalink raw reply
* Re: [PATCH v2 16/16] net: Add support for networking over Thunderbolt cable
From: Mika Westerberg @ 2017-09-27 13:42 UTC (permalink / raw)
To: David Miller
Cc: gregkh, andreas.noever, michael.jamet, yehezkel.bernat,
amir.jer.levy, Mario.Limonciello, lukas, andriy.shevchenko,
andrew, linux-kernel, netdev
In-Reply-To: <20170926.214721.734746621809140934.davem@davemloft.net>
On Tue, Sep 26, 2017 at 09:47:21PM -0700, David Miller wrote:
> From: Mika Westerberg <mika.westerberg@linux.intel.com>
> Date: Mon, 25 Sep 2017 14:07:38 +0300
>
> > +struct thunderbolt_ip_header {
> > + u32 route_hi;
> > + u32 route_lo;
> > + u32 length_sn;
> > + uuid_t uuid;
> > + uuid_t initiator_uuid;
> > + uuid_t target_uuid;
> > + u32 type;
> > + u32 command_id;
> > +} __packed;
>
> Again, the __packed attribute should not be necessary and needs to be
> removed.
OK, will do.
> > +static void tbnet_pull_tail(struct sk_buff *skb)
> > +{
> > + skb_frag_t *frag = &skb_shinfo(skb)->frags[0];
> > + unsigned int pull_len;
> > + void *hdr;
> > +
> > + hdr = skb_frag_address(frag);
> > + pull_len = eth_get_headlen(hdr, TBNET_RX_HDR_SIZE);
> > +
> > + /* Align pull length to size of long to optimize memcpy performance */
> > + skb_copy_to_linear_data(skb, hdr, ALIGN(pull_len, sizeof(long)));
>
> You do not need to copy here, instead you can build SKB's where the
> skb->data points directly at the head of your first frag page memory.
>
> See build_skb().
>
> > + skb = net->skb;
> > + if (!skb) {
> > + skb = netdev_alloc_skb_ip_align(net->dev,
> > + TBNET_RX_HDR_SIZE);
> > + net->skb = skb;
> > + }
> > + if (!skb)
> > + break;
> > +
> > + /* Single small buffer we can copy directly to the
> > + * header part of the skb.
> > + */
> > + if (hdr->frame_count == 1 && frame_size <= TBNET_RX_HDR_SIZE) {
>
> Here you would use build_skb() instead of netdev_alloc_skb*() for the first
> frag, and keep the existing code tacking on subsequent frags using
> skb_add_Rx_frag().
I'm reading kernel-doc of build_skb() (or rather __build_skb()) and it
says caller needs to reserve head room of NET_SKB_PAD and then make sure
there is space for SKB_DATA_ALIGN(skb_shared_info).
Now, in case of ThunderboltIP frames, they look like this:
+---------+
| hdr | 12 bytes
+---------+
| data | 4096 - 12 = 4084 bytes
| |
| |
+---------+
A packet can consist of multiple frames where each have the 12-byte
header and 4084 bytes of TSO/LRO payload except the last one which can
be smaller than 4084.
Using build_skb() then would require to allocate larger buffer, that
includes NET_SKB_PAD + SKB_DATA_ALIGN(skb_shared_info) and that exceeds
page size. Is this something supported by build_skb()? It was not clear
to me based on the code and other users of build_skb() but I may be
missing something.
> > + ret = register_netdev(dev);
> > + if (ret) {
> > + free_netdev(dev);
> > + return ret;
> > + }
> > +
> > + net->handler.uuid = &tbnet_svc_uuid;
> > + net->handler.callback = tbnet_handle_packet,
> > + net->handler.data = net;
> > + tb_register_protocol_handler(&net->handler);
> > +
> > + tb_service_set_drvdata(svc, net);
>
> There could be races here.
>
> At the exact moment you call register_netdev(), your device can be
> brought UP, packets transmitted, etc. You entire set of driver code
> paths can be executed.
>
> The rest of those initializations after register_netdev() probably
> are needed by the rest of the driver to function properly, so may
> need to happen before register_netdev() publishes the device to the
> entire world.
You're right. I'll change the ordering so that register_netdev() happens
last.
Thanks!
^ permalink raw reply
* Re: [PATCH v6 06/11] ARM: dts: sunxi: h3/h5: represent the mdio switch used by sun8i-h3-emac
From: Corentin Labbe @ 2017-09-27 13:47 UTC (permalink / raw)
To: Maxime Ripard
Cc: robh+dt, mark.rutland, wens, linux, catalin.marinas, will.deacon,
peppe.cavallaro, alexandre.torgue, andrew, f.fainelli,
frowand.list, netdev, devicetree, linux-arm-kernel, linux-kernel,
linux-sunxi
In-Reply-To: <20170927101622.v7odmreccwh7ldg2@flea>
On Wed, Sep 27, 2017 at 12:16:22PM +0200, Maxime Ripard wrote:
> On Wed, Sep 27, 2017 at 07:34:09AM +0000, Corentin Labbe wrote:
> > Since dwmac-sun8i could use either an integrated PHY or an external PHY
> > (which could be at same MDIO address), we need to represent this selection
> > by a MDIO switch.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > ---
> > arch/arm/boot/dts/sunxi-h3-h5.dtsi | 31 +++++++++++++++++++++++++------
> > 1 file changed, 25 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > index 3b7d953429a6..a8e9b8f378ba 100644
> > --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > @@ -422,14 +422,33 @@
> > #size-cells = <0>;
> > status = "disabled";
> >
> > - mdio: mdio {
> > + mdio0: mdio {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > - int_mii_phy: ethernet-phy@1 {
> > - compatible = "ethernet-phy-ieee802.3-c22";
> > - reg = <1>;
> > - clocks = <&ccu CLK_BUS_EPHY>;
> > - resets = <&ccu RST_BUS_EPHY>;
> > + compatible = "snps,dwmac-mdio";
> > +
> > + mdio-mux {
> > + compatible = "mdio-mux";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
>
> Newline
>
> > + /* Only one MDIO is usable at the time */
> > + internal_mdio: mdio@1 {
> > + reg = <1>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
>
> Newline
>
> > + int_mii_phy: ethernet-phy@1 {
> > + compatible = "ethernet-phy-ieee802.3-c22";
> > + reg = <1>;
> > + clocks = <&ccu CLK_BUS_EPHY>;
> > + resets = <&ccu RST_BUS_EPHY>;
> > + phy-is-integrated;
> > + };
> > + };
>
> Newline
>
> > + mdio: mdio@2 {
>
> This is quite confusing. Why not call the label external_mdio?
>
I will do it. (at origin I was not changing it for limiting changes on board with external PHY, but now all DT are reverted, it will be easy)
Regards
^ permalink raw reply
* Re: [PATCH v2 net-next 2/2] net/sched: allow flower to match tunnel options
From: Jiri Pirko @ 2017-09-27 13:47 UTC (permalink / raw)
To: Simon Horman
Cc: David Miller, Jiri Pirko, Jamal Hadi Salim, Cong Wang, netdev,
oss-drivers
In-Reply-To: <20170927133731.GA14183@vergenet.net>
Wed, Sep 27, 2017 at 03:37:33PM CEST, simon.horman@netronome.com wrote:
>On Wed, Sep 27, 2017 at 02:56:03PM +0200, Jiri Pirko wrote:
>> Wed, Sep 27, 2017 at 02:52:06PM CEST, simon.horman@netronome.com wrote:
>> >On Wed, Sep 27, 2017 at 01:08:22PM +0200, Jiri Pirko wrote:
>> >> Wed, Sep 27, 2017 at 11:27:33AM CEST, simon.horman@netronome.com wrote:
>> >> >On Wed, Sep 27, 2017 at 11:10:05AM +0200, Jiri Pirko wrote:
>> >> >> Wed, Sep 27, 2017 at 10:16:34AM CEST, simon.horman@netronome.com wrote:
>> >
>> >...
>> >
>> >> >> > enum flow_dissector_key_id {
>> >> >> > FLOW_DISSECTOR_KEY_CONTROL, /* struct flow_dissector_key_control */
>> >> >> > FLOW_DISSECTOR_KEY_BASIC, /* struct flow_dissector_key_basic */
>> >> >> >@@ -205,6 +217,7 @@ enum flow_dissector_key_id {
>> >> >> > FLOW_DISSECTOR_KEY_MPLS, /* struct flow_dissector_key_mpls */
>> >> >> > FLOW_DISSECTOR_KEY_TCP, /* struct flow_dissector_key_tcp */
>> >> >> > FLOW_DISSECTOR_KEY_IP, /* struct flow_dissector_key_ip */
>> >> >> >+ FLOW_DISSECTOR_KEY_ENC_OPTS, /* struct flow_dissector_key_enc_opts */
>> >> >>
>> >> >> I don't see the actual dissection implementation. Where is it?
>> >> >> Did you test the patchset?
>> >> >
>> >> >Yes, I did test it. But it is also possible something went astray along the
>> >> >way and I will retest.
>> >> >
>> >> >I think that the code you are looking for is in
>> >> >fl_classify() in this patch.
>> >>
>> >> The dissection should be done in the flow_dissector. That's the whole
>> >> point in having it generic. You should move it there.
>> >
>> >Coming back to this after lunch, I believe what I have done in this patch
>> >is consistent with handling of other enc fields, which are set in
>> >fl_classify() rather than the dissector. In particular the ip_tunnel_info,
>> >which is used by this patch, is already used in fl_classify().
>>
>> That means the current code is wrong. The dissection should be done in
>> flow_dissector, not in fl_classify.
>
>Would an better approach be to move the fl_classify() below into, say,
>skb_flow_dissect_tunnel_info() and call that from fl_classify().
No. There is one flow dissection function and you just set it up in a
way you need it. Makes no sense to me to split it up in any way.
>
>The reason I suggest this rather than moving the code into
>__skb_flow_dissect() is that currently flower assumes that tunnel_info
>is used if present. While I assume other users of () assume tunnel_info
>is not used even if present.
__skb_flow_dissect should look at what caller wants, then check skb_tunnel_info
only in case it is needed.
>
>> >Without this patch I see:
>> >
>> >
>> >static int fl_classify(struct sk_buff *skb, const struct tcf_proto *tp,
>> > struct tcf_result *res)
>> >{
>> > ...
>> > struct ip_tunnel_info *info;
>> >
>> > ...
>> >
>> > info = skb_tunnel_info(skb);
>> > if (info) {
>> > struct ip_tunnel_key *key = &info->key;
>> >
>> > switch (ip_tunnel_info_af(info)) {
>> > case AF_INET:
>> > skb_key.enc_control.addr_type =
>> > FLOW_DISSECTOR_KEY_IPV4_ADDRS;
>> > skb_key.enc_ipv4.src = key->u.ipv4.src;
>> > skb_key.enc_ipv4.dst = key->u.ipv4.dst;
>> > break;
>> > case AF_INET6:
>> > skb_key.enc_control.addr_type =
>> > FLOW_DISSECTOR_KEY_IPV6_ADDRS;
>> > skb_key.enc_ipv6.src = key->u.ipv6.src;
>> > skb_key.enc_ipv6.dst = key->u.ipv6.dst;
>> > break;
>> > }
>> >
>> > skb_key.enc_key_id.keyid = tunnel_id_to_key32(key->tun_id);
>> > skb_key.enc_tp.src = key->tp_src;
>> > skb_key.enc_tp.dst = key->tp_dst;
>> > }
>> >
>> > ...
>> >}
>> >
>> >This patch adds the following inside the if() clause above:
>> >
>> > if (info->options_len) {
>> > skb_key.enc_opts.len = info->options_len;
>> > ip_tunnel_info_opts_get(skb_key.enc_opts.data, info);
>> > }
>> >
>> >
^ permalink raw reply
* Re: [PATCH v2 net-next 2/2] net/sched: allow flower to match tunnel options
From: Simon Horman @ 2017-09-27 13:50 UTC (permalink / raw)
To: Jiri Pirko
Cc: David Miller, Jiri Pirko, Jamal Hadi Salim, Cong Wang, netdev,
oss-drivers
In-Reply-To: <20170927134750.GI1944@nanopsycho.orion>
On Wed, Sep 27, 2017 at 03:47:50PM +0200, Jiri Pirko wrote:
> Wed, Sep 27, 2017 at 03:37:33PM CEST, simon.horman@netronome.com wrote:
> >On Wed, Sep 27, 2017 at 02:56:03PM +0200, Jiri Pirko wrote:
> >> Wed, Sep 27, 2017 at 02:52:06PM CEST, simon.horman@netronome.com wrote:
> >> >On Wed, Sep 27, 2017 at 01:08:22PM +0200, Jiri Pirko wrote:
> >> >> Wed, Sep 27, 2017 at 11:27:33AM CEST, simon.horman@netronome.com wrote:
> >> >> >On Wed, Sep 27, 2017 at 11:10:05AM +0200, Jiri Pirko wrote:
> >> >> >> Wed, Sep 27, 2017 at 10:16:34AM CEST, simon.horman@netronome.com wrote:
> >> >
> >> >...
> >> >
> >> >> >> > enum flow_dissector_key_id {
> >> >> >> > FLOW_DISSECTOR_KEY_CONTROL, /* struct flow_dissector_key_control */
> >> >> >> > FLOW_DISSECTOR_KEY_BASIC, /* struct flow_dissector_key_basic */
> >> >> >> >@@ -205,6 +217,7 @@ enum flow_dissector_key_id {
> >> >> >> > FLOW_DISSECTOR_KEY_MPLS, /* struct flow_dissector_key_mpls */
> >> >> >> > FLOW_DISSECTOR_KEY_TCP, /* struct flow_dissector_key_tcp */
> >> >> >> > FLOW_DISSECTOR_KEY_IP, /* struct flow_dissector_key_ip */
> >> >> >> >+ FLOW_DISSECTOR_KEY_ENC_OPTS, /* struct flow_dissector_key_enc_opts */
> >> >> >>
> >> >> >> I don't see the actual dissection implementation. Where is it?
> >> >> >> Did you test the patchset?
> >> >> >
> >> >> >Yes, I did test it. But it is also possible something went astray along the
> >> >> >way and I will retest.
> >> >> >
> >> >> >I think that the code you are looking for is in
> >> >> >fl_classify() in this patch.
> >> >>
> >> >> The dissection should be done in the flow_dissector. That's the whole
> >> >> point in having it generic. You should move it there.
> >> >
> >> >Coming back to this after lunch, I believe what I have done in this patch
> >> >is consistent with handling of other enc fields, which are set in
> >> >fl_classify() rather than the dissector. In particular the ip_tunnel_info,
> >> >which is used by this patch, is already used in fl_classify().
> >>
> >> That means the current code is wrong. The dissection should be done in
> >> flow_dissector, not in fl_classify.
> >
> >Would an better approach be to move the fl_classify() below into, say,
> >skb_flow_dissect_tunnel_info() and call that from fl_classify().
>
> No. There is one flow dissection function and you just set it up in a
> way you need it. Makes no sense to me to split it up in any way.
>
>
> >
> >The reason I suggest this rather than moving the code into
> >__skb_flow_dissect() is that currently flower assumes that tunnel_info
> >is used if present. While I assume other users of () assume tunnel_info
> >is not used even if present.
>
> __skb_flow_dissect should look at what caller wants, then check skb_tunnel_info
> only in case it is needed.
Ok, do you think it is sufficient for __skb_flow_dissect to look at the
tunnel keys, say FLOW_DISSECTOR_KEY_ENC_*? I am a bit concerned this may
break flower as it look at the tunnel info unconditionally.
^ permalink raw reply
* Re: [PATCH v2 net-next 2/2] net/sched: allow flower to match tunnel options
From: Jiri Pirko @ 2017-09-27 14:00 UTC (permalink / raw)
To: Simon Horman
Cc: David Miller, Jiri Pirko, Jamal Hadi Salim, Cong Wang, netdev,
oss-drivers, amir
In-Reply-To: <20170927135042.GB14183@vergenet.net>
Wed, Sep 27, 2017 at 03:50:44PM CEST, simon.horman@netronome.com wrote:
>On Wed, Sep 27, 2017 at 03:47:50PM +0200, Jiri Pirko wrote:
>> Wed, Sep 27, 2017 at 03:37:33PM CEST, simon.horman@netronome.com wrote:
>> >On Wed, Sep 27, 2017 at 02:56:03PM +0200, Jiri Pirko wrote:
>> >> Wed, Sep 27, 2017 at 02:52:06PM CEST, simon.horman@netronome.com wrote:
>> >> >On Wed, Sep 27, 2017 at 01:08:22PM +0200, Jiri Pirko wrote:
>> >> >> Wed, Sep 27, 2017 at 11:27:33AM CEST, simon.horman@netronome.com wrote:
>> >> >> >On Wed, Sep 27, 2017 at 11:10:05AM +0200, Jiri Pirko wrote:
>> >> >> >> Wed, Sep 27, 2017 at 10:16:34AM CEST, simon.horman@netronome.com wrote:
>> >> >
>> >> >...
>> >> >
>> >> >> >> > enum flow_dissector_key_id {
>> >> >> >> > FLOW_DISSECTOR_KEY_CONTROL, /* struct flow_dissector_key_control */
>> >> >> >> > FLOW_DISSECTOR_KEY_BASIC, /* struct flow_dissector_key_basic */
>> >> >> >> >@@ -205,6 +217,7 @@ enum flow_dissector_key_id {
>> >> >> >> > FLOW_DISSECTOR_KEY_MPLS, /* struct flow_dissector_key_mpls */
>> >> >> >> > FLOW_DISSECTOR_KEY_TCP, /* struct flow_dissector_key_tcp */
>> >> >> >> > FLOW_DISSECTOR_KEY_IP, /* struct flow_dissector_key_ip */
>> >> >> >> >+ FLOW_DISSECTOR_KEY_ENC_OPTS, /* struct flow_dissector_key_enc_opts */
>> >> >> >>
>> >> >> >> I don't see the actual dissection implementation. Where is it?
>> >> >> >> Did you test the patchset?
>> >> >> >
>> >> >> >Yes, I did test it. But it is also possible something went astray along the
>> >> >> >way and I will retest.
>> >> >> >
>> >> >> >I think that the code you are looking for is in
>> >> >> >fl_classify() in this patch.
>> >> >>
>> >> >> The dissection should be done in the flow_dissector. That's the whole
>> >> >> point in having it generic. You should move it there.
>> >> >
>> >> >Coming back to this after lunch, I believe what I have done in this patch
>> >> >is consistent with handling of other enc fields, which are set in
>> >> >fl_classify() rather than the dissector. In particular the ip_tunnel_info,
>> >> >which is used by this patch, is already used in fl_classify().
>> >>
>> >> That means the current code is wrong. The dissection should be done in
>> >> flow_dissector, not in fl_classify.
>> >
>> >Would an better approach be to move the fl_classify() below into, say,
>> >skb_flow_dissect_tunnel_info() and call that from fl_classify().
>>
>> No. There is one flow dissection function and you just set it up in a
>> way you need it. Makes no sense to me to split it up in any way.
>>
>>
>> >
>> >The reason I suggest this rather than moving the code into
>> >__skb_flow_dissect() is that currently flower assumes that tunnel_info
>> >is used if present. While I assume other users of () assume tunnel_info
>> >is not used even if present.
>>
>> __skb_flow_dissect should look at what caller wants, then check skb_tunnel_info
>> only in case it is needed.
>
>Ok, do you think it is sufficient for __skb_flow_dissect to look at the
>tunnel keys, say FLOW_DISSECTOR_KEY_ENC_*? I am a bit concerned this may
>break flower as it look at the tunnel info unconditionally.
yeah. When flower needs that, it will get that from the flow dissector.
I don't see why it would break anything. Again, existing code is wrong:
commit bc3103f1ed405de587fa43d8b0671e615505a700
Author: Amir Vadai <amir@vadai.me>
Date: Thu Sep 8 16:23:47 2016 +0300
net/sched: cls_flower: Classify packet in ip tunnels
The dissection has to be moved to flow dissector.
^ permalink raw reply
* Re: [PATCH v6 05/11] dt-bindings: net: dwmac-sun8i: update documentation about integrated PHY
From: Andrew Lunn @ 2017-09-27 14:02 UTC (permalink / raw)
To: Corentin Labbe
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o, f.fainelli-Re5JQEeQqe8AvxtiuMwx3w,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170927073414.17361-6-clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Corentin
> +Required properties for the mdio-mux node:
> + - compatible = "mdio-mux"
This is too generic. Please add a more specific compatible for this
particular mux. You can keep "mdio-mux", since that is what the MDIO
subsystem will look for.
> +Required properties of the integrated phy node:
> - clocks: a phandle to the reference clock for the EPHY
> - resets: a phandle to the reset control for the EPHY
> +- phy-is-integrated
So the last thing you said is that the mux is not the problem
here. Something else is locking up. Did you discover what?
I really would like phy-is-integrated to go away.
Andrew
^ permalink raw reply
* [PATCH net-next] libbpf: use map_flags when creating maps
From: Craig Gallek @ 2017-09-27 14:04 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, David S . Miller
Cc: Chonggang Li, netdev
From: Craig Gallek <kraig@google.com>
This extends struct bpf_map_def to include a flags field. Note that
this has the potential to break the validation logic in
bpf_object__validate_maps and bpf_object__init_maps as they use
sizeof(struct bpf_map_def) as a minimal allowable size of a map section.
Any bpf program compiled with a smaller struct bpf_map_def will fail this
check.
I don't believe this will be an issue in practice as both compile-time
definitions of struct bpf_map_def (in samples/bpf/bpf_load.h and
tools/testing/selftests/bpf/bpf_helpers.h) have always been larger
than this newly updated version in libbpf.h.
Signed-off-by: Craig Gallek <kraig@google.com>
---
tools/lib/bpf/libbpf.c | 2 +-
tools/lib/bpf/libbpf.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 35f6dfcdc565..6bea85f260a3 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -874,7 +874,7 @@ bpf_object__create_maps(struct bpf_object *obj)
def->key_size,
def->value_size,
def->max_entries,
- 0);
+ def->map_flags);
if (*pfd < 0) {
size_t j;
int err = *pfd;
diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
index 7959086eb9c9..6e20003109e0 100644
--- a/tools/lib/bpf/libbpf.h
+++ b/tools/lib/bpf/libbpf.h
@@ -207,6 +207,7 @@ struct bpf_map_def {
unsigned int key_size;
unsigned int value_size;
unsigned int max_entries;
+ unsigned int map_flags;
};
/*
--
2.14.2.822.g60be5d43e6-goog
^ permalink raw reply related
* Re: [PATCH v2 net-next 2/2] net/sched: allow flower to match tunnel options
From: Simon Horman @ 2017-09-27 14:09 UTC (permalink / raw)
To: Jiri Pirko
Cc: David Miller, Jiri Pirko, Jamal Hadi Salim, Cong Wang, netdev,
oss-drivers, amir
In-Reply-To: <20170927140011.GJ1944@nanopsycho.orion>
On Wed, Sep 27, 2017 at 04:00:11PM +0200, Jiri Pirko wrote:
> Wed, Sep 27, 2017 at 03:50:44PM CEST, simon.horman@netronome.com wrote:
> >On Wed, Sep 27, 2017 at 03:47:50PM +0200, Jiri Pirko wrote:
> >> Wed, Sep 27, 2017 at 03:37:33PM CEST, simon.horman@netronome.com wrote:
> >> >On Wed, Sep 27, 2017 at 02:56:03PM +0200, Jiri Pirko wrote:
> >> >> Wed, Sep 27, 2017 at 02:52:06PM CEST, simon.horman@netronome.com wrote:
> >> >> >On Wed, Sep 27, 2017 at 01:08:22PM +0200, Jiri Pirko wrote:
> >> >> >> Wed, Sep 27, 2017 at 11:27:33AM CEST, simon.horman@netronome.com wrote:
> >> >> >> >On Wed, Sep 27, 2017 at 11:10:05AM +0200, Jiri Pirko wrote:
> >> >> >> >> Wed, Sep 27, 2017 at 10:16:34AM CEST, simon.horman@netronome.com wrote:
> >> >> >
> >> >> >...
> >> >> >
> >> >> >> >> > enum flow_dissector_key_id {
> >> >> >> >> > FLOW_DISSECTOR_KEY_CONTROL, /* struct flow_dissector_key_control */
> >> >> >> >> > FLOW_DISSECTOR_KEY_BASIC, /* struct flow_dissector_key_basic */
> >> >> >> >> >@@ -205,6 +217,7 @@ enum flow_dissector_key_id {
> >> >> >> >> > FLOW_DISSECTOR_KEY_MPLS, /* struct flow_dissector_key_mpls */
> >> >> >> >> > FLOW_DISSECTOR_KEY_TCP, /* struct flow_dissector_key_tcp */
> >> >> >> >> > FLOW_DISSECTOR_KEY_IP, /* struct flow_dissector_key_ip */
> >> >> >> >> >+ FLOW_DISSECTOR_KEY_ENC_OPTS, /* struct flow_dissector_key_enc_opts */
> >> >> >> >>
> >> >> >> >> I don't see the actual dissection implementation. Where is it?
> >> >> >> >> Did you test the patchset?
> >> >> >> >
> >> >> >> >Yes, I did test it. But it is also possible something went astray along the
> >> >> >> >way and I will retest.
> >> >> >> >
> >> >> >> >I think that the code you are looking for is in
> >> >> >> >fl_classify() in this patch.
> >> >> >>
> >> >> >> The dissection should be done in the flow_dissector. That's the whole
> >> >> >> point in having it generic. You should move it there.
> >> >> >
> >> >> >Coming back to this after lunch, I believe what I have done in this patch
> >> >> >is consistent with handling of other enc fields, which are set in
> >> >> >fl_classify() rather than the dissector. In particular the ip_tunnel_info,
> >> >> >which is used by this patch, is already used in fl_classify().
> >> >>
> >> >> That means the current code is wrong. The dissection should be done in
> >> >> flow_dissector, not in fl_classify.
> >> >
> >> >Would an better approach be to move the fl_classify() below into, say,
> >> >skb_flow_dissect_tunnel_info() and call that from fl_classify().
> >>
> >> No. There is one flow dissection function and you just set it up in a
> >> way you need it. Makes no sense to me to split it up in any way.
> >>
> >>
> >> >
> >> >The reason I suggest this rather than moving the code into
> >> >__skb_flow_dissect() is that currently flower assumes that tunnel_info
> >> >is used if present. While I assume other users of () assume tunnel_info
> >> >is not used even if present.
> >>
> >> __skb_flow_dissect should look at what caller wants, then check skb_tunnel_info
> >> only in case it is needed.
> >
> >Ok, do you think it is sufficient for __skb_flow_dissect to look at the
> >tunnel keys, say FLOW_DISSECTOR_KEY_ENC_*? I am a bit concerned this may
> >break flower as it look at the tunnel info unconditionally.
>
> yeah. When flower needs that, it will get that from the flow dissector.
> I don't see why it would break anything. Again, existing code is wrong:
I understand that you think the existing code is wrong.
But I also want to try not to add new bugs.
I am concerned about the case where none of FLOW_DISSECTOR_KEY_ENC_* are
set but flower currently dissects the tunnel info anyway. If I make
dissection of tunnel info dependent on FLOW_DISSECTOR_KEY_ENC_*
that may change things.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox