* Re: tc: Using u32 filter
From: Jiri Pirko @ 2018-04-27 15:04 UTC (permalink / raw)
To: Jose Abreu; +Cc: netdev@vger.kernel.org, Joao Pinto
In-Reply-To: <27482470-930e-916d-2ace-deedf3019369@synopsys.com>
Fri, Apr 27, 2018 at 04:15:46PM CEST, Jose.Abreu@synopsys.com wrote:
>Hi,
>
>I'm trying to use u32 filter to filter specific fields of packets
>by HW *only* but I'm having a hard time in trying to run tc to
>configure it.
>I implemented a dummy .ndo_setup_tc callback which always returns
>success and I set NETIF_F_HW_TC field in hw_features. Then I run
Did you register a block cb?
>tc, like this:
>
> # tc filter add dev eth0 u32 skip_sw sample u32 20 ffff at 0
>
>At this stage I'm not really caring about the packet content (the
>"20 ffff at 0"), I just want to see the configuration reaching my
>driver but I'm getting a "RTNETLINK answers: Operation not
>supported" error.
>
>Can you tell me what I'm I doing wrong?
>
>Thanks and Best Regards,
>Jose Miguel Abreu
^ permalink raw reply
* Re: [net 1/1] tipc: fix bug in function tipc_nl_node_dump_monitor
From: David Miller @ 2018-04-27 15:04 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, mohan.krishna.ghanta.krishnamurthy, tung.q.nguyen,
hoang.h.le, canh.d.luu, ying.xue, tipc-discussion
In-Reply-To: <1524673765-28878-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Wed, 25 Apr 2018 18:29:25 +0200
> Commit 36a50a989ee8 ("tipc: fix infinite loop when dumping link monitor
> summary") intended to fix a problem with user tool looping when max
> number of bearers are enabled.
>
> Unfortunately, the wrong version of the commit was posted, so the
> problem was not solved at all.
>
> This commit adds the missing part.
>
> Fixes: 36a50a989ee8 ("tipc: fix infinite loop when dumping link monitor summary")
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] l2tp: centralise parsing of sockaddr_pppol2tp*
From: David Miller @ 2018-04-27 15:03 UTC (permalink / raw)
To: g.nault; +Cc: netdev, jchapman
In-Reply-To: <fa923854b6bdb86990cc26c8e90e14a2dc906559.1524670082.git.g.nault@alphalink.fr>
From: Guillaume Nault <g.nault@alphalink.fr>
Date: Wed, 25 Apr 2018 17:50:31 +0200
> @DaveM, I have some know bugs in pppol2tp_connect() that I'm going to
> work on soon. That's probably going to create some conflicts between
> net and net-next. They should be easy to resolve, but if you prefer, I
> can resend this patch later, after all known issues get fixed.
Let's fix the bugs in net first, then do this cleanup on top after those
fixes make it into net-next.
Thanks!
^ permalink raw reply
* Re: [PATCH v1 net-next] lan78xx: Lan7801 Support for Fixed PHY
From: David Miller @ 2018-04-27 15:00 UTC (permalink / raw)
To: raghuramchary.jallipalli; +Cc: netdev, unglinuxdriver, woojung.huh
In-Reply-To: <20180425064306.5513-1-raghuramchary.jallipalli@microchip.com>
From: Raghuram Chary J <raghuramchary.jallipalli@microchip.com>
Date: Wed, 25 Apr 2018 12:13:06 +0530
> Adding Fixed PHY support to the lan78xx driver.
>
> Signed-off-by: Raghuram Chary J <raghuramchary.jallipalli@microchip.com>
> ---
> v0->v1:
> * Remove driver version #define
> * Modify netdev_info to netdev_dbg
> * Move lan7801 specific to new routine and add switch case
> * Minor cleanup
This patch doesn't apply cleanly to net-next, please respin.
^ permalink raw reply
* Re: [PATCH net-next v2 4/5] ipv6: sr: Add seg6local action End.BPF
From: David Miller @ 2018-04-27 14:59 UTC (permalink / raw)
To: m.xhonneux; +Cc: netdev, dlebrun, alexei.starovoitov
In-Reply-To: <223e33f96b2cb9868a55a686c5d9321162a67ddb.1524591163.git.m.xhonneux@gmail.com>
From: Mathieu Xhonneux <m.xhonneux@gmail.com>
Date: Tue, 24 Apr 2018 18:44:15 +0100
> This patch adds the End.BPF action to the LWT seg6local infrastructure.
> This action works like any other seg6local End action, meaning that an IPv6
> header with SRH is needed, whose DA has to be equal to the SID of the
> action. It will also advance the SRH to the next segment, the BPF program
> does not have to take care of this.
I'd like to see some BPF developers review this change.
But on my side I wonder if, instead of validating the whole thing afterwards,
we should make the helpers accessible by the eBPF program validate the changes
as they are made.
^ permalink raw reply
* Re: [PATCH v2] net: qrtr: Expose tunneling endpoint to user space
From: David Miller @ 2018-04-27 14:55 UTC (permalink / raw)
To: bjorn.andersson; +Cc: clew, linux-kernel, netdev, linux-arm-msm
In-Reply-To: <20180423214653.10016-1-bjorn.andersson@linaro.org>
From: Bjorn Andersson <bjorn.andersson@linaro.org>
Date: Mon, 23 Apr 2018 14:46:53 -0700
> + count = min_t(size_t, iov_iter_count(to), skb->len);
> + if (copy_to_iter(skb->data, count, to) != count)
> + count = -EFAULT;
> +
> + kfree_skb(skb);
As noted by Chris, you should be using consume_skb() here.
Thanks.
^ permalink raw reply
* Re: ip6-in-ip{4,6} ipsec tunnel issues with 1280 MTU
From: David Ahern @ 2018-04-27 14:48 UTC (permalink / raw)
To: Ashwanth Goli, Paolo Abeni; +Cc: netdev, maloney, edumazet, netdev-owner
In-Reply-To: <a3e39b94de731f86d2e9ecd8f0230643@codeaurora.org>
On 4/27/18 5:02 AM, Ashwanth Goli wrote:
> On 2018-04-26 17:21, Paolo Abeni wrote:
>> Hi,
>>
>> [fixed CC list]
>>
>> On Wed, 2018-04-25 at 21:43 +0530, Ashwanth Goli wrote:
>>> Hi Pablo,
>>
>> Actually I'm Paolo, but yours is a recurring mistake ;)
>>
>>> I am noticing an issue similar to the one reported by Alexis Perez
>>> [Regression for ip6-in-ip4 IPsec tunnel in 4.14.16]
>>>
>>> In my IPsec setup outer MTU is set to 1280, ip6_setup_cork sees an MTU
>>> less than IPV6_MIN_MTU because of the tunnel headers. -EINVAL is being
>>> returned as a result of the MTU check that got added with below patch.
If you know you are running ipsec over the link why are you setting the
outer MTU to 1280? RFC 2460 suggests the fragmentation of packets for
links with MTU < 1280 should be done below the IPv6 layer:
5. Packet Size Issues
IPv6 requires that every link in the internet have an MTU of 1280
octets or greater. On any link that cannot convey a 1280-octet
packet in one piece, link-specific fragmentation and reassembly must
be provided at a layer below IPv6.
Links that have a configurable MTU (for example, PPP links [RFC-
1661]) must be configured to have an MTU of at least 1280 octets; it
is recommended that they be configured with an MTU of 1500 octets or
greater, to accommodate possible encapsulations (i.e., tunneling)
without incurring IPv6-layer fragmentation.
^ permalink raw reply
* Re: Request for stable 4.14.x inclusion: net: don't call update_pmtu unconditionally
From: Greg KH @ 2018-04-27 14:45 UTC (permalink / raw)
To: Thomas Deutschmann; +Cc: stable, davem, nicolas.dichtel, netdev
In-Reply-To: <20180427135125.GA31860@kroah.com>
On Fri, Apr 27, 2018 at 03:51:25PM +0200, Greg KH wrote:
> On Fri, Apr 27, 2018 at 02:20:07PM +0200, Thomas Deutschmann wrote:
> > On 2018-04-22 23:50, Thomas Deutschmann wrote:
> > > Hi,
> > >
> > > please add
> > >
> > >> From f15ca723c1ebe6c1a06bc95fda6b62cd87b44559 Mon Sep 17 00:00:00 2001
> > >> From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> > >> Date: Thu, 25 Jan 2018 19:03:03 +0100
> > >> Subject: net: don't call update_pmtu unconditionally
> > >>
> > >> Some dst_ops (e.g. md_dst_ops)) doesn't set this handler. It may result to:
> > >> "BUG: unable to handle kernel NULL pointer dereference at (null)"
> > >>
> > >> Let's add a helper to check if update_pmtu is available before calling it.
> > >>
> > >> Fixes: 52a589d51f10 ("geneve: update skb dst pmtu on tx path")
> > >> Fixes: a93bf0ff4490 ("vxlan: update skb dst pmtu on tx path")
> > >> CC: Roman Kapl <code@rkapl.cz>
> > >> CC: Xin Long <lucien.xin@gmail.com>
> > >> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> > >> Signed-off-by: David S. Miller <davem@davemloft.net>
> > >
> > > to 4.14.x.
> > >
> > > This fixes NULL derefs caused by a93bf0ff4490 ("vxlan: update
> > > skb dst pmtu on tx path"), which was backported to 4.14.24.
> >
> > *ping* - Not yet applied and not yet queued. Is there a problem with the
> > patch which prevents a cherry-pick for 4.14.x?
>
> This looks like an "obvious" fix for me to pick up.
Well, it would be "obvious" if it actually applied to the 4.14.y tree :(
Thomas, did you try this patch out? I can't apply it as-is, it will
need a backport. Please work on that, and test it out, as I don't get
the impression that you did that here.
Then post the working backport and I'll be glad to consider it for
future 4.14.y releases.
thanks,
greg k-h
^ permalink raw reply
* Re: Request for stable 4.14.x inclusion: net: don't call update_pmtu unconditionally
From: David Miller @ 2018-04-27 14:39 UTC (permalink / raw)
To: gregkh; +Cc: whissi, stable, nicolas.dichtel, netdev
In-Reply-To: <20180427135125.GA31860@kroah.com>
From: Greg KH <gregkh@linuxfoundation.org>
Date: Fri, 27 Apr 2018 15:51:25 +0200
> On Fri, Apr 27, 2018 at 02:20:07PM +0200, Thomas Deutschmann wrote:
>> On 2018-04-22 23:50, Thomas Deutschmann wrote:
>> > Hi,
>> >
>> > please add
>> >
>> >> From f15ca723c1ebe6c1a06bc95fda6b62cd87b44559 Mon Sep 17 00:00:00 2001
>> >> From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>> >> Date: Thu, 25 Jan 2018 19:03:03 +0100
>> >> Subject: net: don't call update_pmtu unconditionally
>> >>
>> >> Some dst_ops (e.g. md_dst_ops)) doesn't set this handler. It may result to:
>> >> "BUG: unable to handle kernel NULL pointer dereference at (null)"
>> >>
>> >> Let's add a helper to check if update_pmtu is available before calling it.
>> >>
>> >> Fixes: 52a589d51f10 ("geneve: update skb dst pmtu on tx path")
>> >> Fixes: a93bf0ff4490 ("vxlan: update skb dst pmtu on tx path")
>> >> CC: Roman Kapl <code@rkapl.cz>
>> >> CC: Xin Long <lucien.xin@gmail.com>
>> >> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>> >> Signed-off-by: David S. Miller <davem@davemloft.net>
>> >
>> > to 4.14.x.
>> >
>> > This fixes NULL derefs caused by a93bf0ff4490 ("vxlan: update
>> > skb dst pmtu on tx path"), which was backported to 4.14.24.
>>
>> *ping* - Not yet applied and not yet queued. Is there a problem with the
>> patch which prevents a cherry-pick for 4.14.x?
>
> This looks like an "obvious" fix for me to pick up.
>
> Dave, any objections for me just grabbing it as-is?
No objections, thanks everyone.
^ permalink raw reply
* tc: Using u32 filter
From: Jose Abreu @ 2018-04-27 14:15 UTC (permalink / raw)
To: netdev@vger.kernel.org; +Cc: Joao Pinto
Hi,
I'm trying to use u32 filter to filter specific fields of packets
by HW *only* but I'm having a hard time in trying to run tc to
configure it.
I implemented a dummy .ndo_setup_tc callback which always returns
success and I set NETIF_F_HW_TC field in hw_features. Then I run
tc, like this:
# tc filter add dev eth0 u32 skip_sw sample u32 20 ffff at 0
At this stage I'm not really caring about the packet content (the
"20 ffff at 0"), I just want to see the configuration reaching my
driver but I'm getting a "RTNETLINK answers: Operation not
supported" error.
Can you tell me what I'm I doing wrong?
Thanks and Best Regards,
Jose Miguel Abreu
^ permalink raw reply
* [PATCH net 2/2] sfc: fix ARFS expiry check on EF10
From: Edward Cree @ 2018-04-27 14:08 UTC (permalink / raw)
To: linux-net-drivers, David Miller; +Cc: netdev
In-Reply-To: <480b987f-2dad-96d9-22ee-d2c25f0c3d92@solarflare.com>
Owing to a missing conditional, the result of rps_may_expire_flow() was
being ignored and filters were being removed even if we'd decided not to
expire them.
Fixes: f8d6203780b7 ("sfc: ARFS filter IDs")
Signed-off-by: Edward Cree <ecree@solarflare.com>
---
drivers/net/ethernet/sfc/ef10.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/sfc/ef10.c b/drivers/net/ethernet/sfc/ef10.c
index 63036d9bf3e6..d90a7b1f4088 100644
--- a/drivers/net/ethernet/sfc/ef10.c
+++ b/drivers/net/ethernet/sfc/ef10.c
@@ -4784,8 +4784,9 @@ static bool efx_ef10_filter_rfs_expire_one(struct efx_nic *efx, u32 flow_id,
* will set rule->filter_id to EFX_ARFS_FILTER_ID_PENDING, meaning that
* the rule is not removed by efx_rps_hash_del() below.
*/
- ret = efx_ef10_filter_remove_internal(efx, 1U << spec->priority,
- filter_idx, true) == 0;
+ if (ret)
+ ret = efx_ef10_filter_remove_internal(efx, 1U << spec->priority,
+ filter_idx, true) == 0;
/* While we can't safely dereference rule (we dropped the lock), we can
* still test it for NULL.
*/
^ permalink raw reply related
* [PATCH net 1/2] sfc: Use filter index rather than ID for rps_flow_id table
From: Edward Cree @ 2018-04-27 14:08 UTC (permalink / raw)
To: linux-net-drivers, David Miller; +Cc: netdev
In-Reply-To: <480b987f-2dad-96d9-22ee-d2c25f0c3d92@solarflare.com>
efx->type->filter_insert() returns an ID rather than the index that
efx->type->filter_async_insert() used to, which causes it to exceed
efx->type->max_rx_ip_filters on some EF10 configurations, leading to out-
of-bounds array writes.
So, in efx_filter_rfs_work(), convert this back into an index (which is
what the remove call in the expiry path expects, anyway).
Fixes: 3af0f34290f6 ("sfc: replace asynchronous filter operations")
Signed-off-by: Edward Cree <ecree@solarflare.com>
---
drivers/net/ethernet/sfc/rx.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/sfc/rx.c b/drivers/net/ethernet/sfc/rx.c
index 64a94f242027..d2e254f2f72b 100644
--- a/drivers/net/ethernet/sfc/rx.c
+++ b/drivers/net/ethernet/sfc/rx.c
@@ -839,6 +839,8 @@ static void efx_filter_rfs_work(struct work_struct *data)
int rc;
rc = efx->type->filter_insert(efx, &req->spec, true);
+ if (rc >= 0)
+ rc %= efx->type->max_rx_ip_filters;
if (efx->rps_hash_table) {
spin_lock_bh(&efx->rps_hash_lock);
rule = efx_rps_hash_find(efx, &req->spec);
^ permalink raw reply related
* [PATCH net 0/2] sfc: more ARFS fixes
From: Edward Cree @ 2018-04-27 14:07 UTC (permalink / raw)
To: linux-net-drivers, David Miller; +Cc: netdev
A couple more bits of breakage in my recent ARFS and async filters work.
Patch #1 in particular fixes a bug that leads to memory trampling and
consequent crashes.
Edward Cree (2):
sfc: Use filter index rather than ID for rps_flow_id table
sfc: fix ARFS expiry check on EF10
drivers/net/ethernet/sfc/ef10.c | 5 +++--
drivers/net/ethernet/sfc/rx.c | 2 ++
2 files changed, 5 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCH 2/2] bpf: btf: remove a couple conditions
From: Dan Carpenter @ 2018-04-27 14:04 UTC (permalink / raw)
To: Alexei Starovoitov, Martin KaFai Lau
Cc: Daniel Borkmann, netdev, linux-kernel, kernel-janitors
We know "err" is zero so we can remove these and pull the code in one
indent level.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
This applies to the BPF tree (linux-next)
diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
index e631b6fd60d3..7cb0905f37c2 100644
--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c
@@ -1973,16 +1973,14 @@ static struct btf *btf_parse(void __user *btf_data, u32 btf_data_size,
if (err)
goto errout;
- if (!err && log->level && bpf_verifier_log_full(log)) {
+ if (log->level && bpf_verifier_log_full(log)) {
err = -ENOSPC;
goto errout;
}
- if (!err) {
- btf_verifier_env_free(env);
- btf_get(btf);
- return btf;
- }
+ btf_verifier_env_free(env);
+ btf_get(btf);
+ return btf;
errout:
btf_verifier_env_free(env);
^ permalink raw reply related
* [PATCH 1/2] bpf: btf: silence uninitialize variable warnings
From: Dan Carpenter @ 2018-04-27 14:04 UTC (permalink / raw)
To: Alexei Starovoitov, Martin KaFai Lau
Cc: Daniel Borkmann, netdev, linux-kernel, kernel-janitors
Smatch complains that size can be uninitialized if btf_type_id_size()
returns NULL. It seems reasonable enough to check for that.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
This goes to the BPF tree (linux-next).
diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
index 22e1046a1a86..e631b6fd60d3 100644
--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c
@@ -1229,7 +1229,8 @@ static int btf_array_check_member(struct btf_verifier_env *env,
}
array_type_id = member->type;
- btf_type_id_size(btf, &array_type_id, &array_size);
+ if (!btf_type_id_size(btf, &array_type_id, &array_size))
+ return -EINVAL;
struct_size = struct_type->size;
bytes_offset = BITS_ROUNDDOWN_BYTES(struct_bits_off);
if (struct_size - bytes_offset < array_size) {
@@ -1351,6 +1352,8 @@ static void btf_array_seq_show(const struct btf *btf, const struct btf_type *t,
elem_type_id = array->type;
elem_type = btf_type_id_size(btf, &elem_type_id, &elem_size);
+ if (!elem_type)
+ return;
elem_ops = btf_type_ops(elem_type);
seq_puts(m, "[");
for (i = 0; i < array->nelems; i++) {
^ permalink raw reply related
* Re: Request for stable 4.14.x inclusion: net: don't call update_pmtu unconditionally
From: Greg KH @ 2018-04-27 13:51 UTC (permalink / raw)
To: Thomas Deutschmann; +Cc: stable, davem, nicolas.dichtel, netdev
In-Reply-To: <40404f68-8328-8ed2-15bf-9de38830f796@gentoo.org>
On Fri, Apr 27, 2018 at 02:20:07PM +0200, Thomas Deutschmann wrote:
> On 2018-04-22 23:50, Thomas Deutschmann wrote:
> > Hi,
> >
> > please add
> >
> >> From f15ca723c1ebe6c1a06bc95fda6b62cd87b44559 Mon Sep 17 00:00:00 2001
> >> From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> >> Date: Thu, 25 Jan 2018 19:03:03 +0100
> >> Subject: net: don't call update_pmtu unconditionally
> >>
> >> Some dst_ops (e.g. md_dst_ops)) doesn't set this handler. It may result to:
> >> "BUG: unable to handle kernel NULL pointer dereference at (null)"
> >>
> >> Let's add a helper to check if update_pmtu is available before calling it.
> >>
> >> Fixes: 52a589d51f10 ("geneve: update skb dst pmtu on tx path")
> >> Fixes: a93bf0ff4490 ("vxlan: update skb dst pmtu on tx path")
> >> CC: Roman Kapl <code@rkapl.cz>
> >> CC: Xin Long <lucien.xin@gmail.com>
> >> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> >> Signed-off-by: David S. Miller <davem@davemloft.net>
> >
> > to 4.14.x.
> >
> > This fixes NULL derefs caused by a93bf0ff4490 ("vxlan: update
> > skb dst pmtu on tx path"), which was backported to 4.14.24.
>
> *ping* - Not yet applied and not yet queued. Is there a problem with the
> patch which prevents a cherry-pick for 4.14.x?
This looks like an "obvious" fix for me to pick up.
Dave, any objections for me just grabbing it as-is?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH net-next v4] Add Common Applications Kept Enhanced (cake) qdisc
From: Toke Høiland-Jørgensen @ 2018-04-27 13:45 UTC (permalink / raw)
To: Eric Dumazet, netdev; +Cc: cake, Dave Taht
In-Reply-To: <673fc1b9-809c-2e14-a054-7eb8beb9a8fd@gmail.com>
Eric Dumazet <eric.dumazet@gmail.com> writes:
> On 04/27/2018 06:38 AM, Toke Høiland-Jørgensen wrote:
>>
>> Ah, right. Will fix.
>>
>> Is it safe to dereference the iph pointer before calling
>> pskb_may_pull()?
>
> No, please take a look at ip_rcv() for a typical use case.
Will do, thanks.
-Toke
^ permalink raw reply
* Re: [PATCH net-next v4] Add Common Applications Kept Enhanced (cake) qdisc
From: Eric Dumazet @ 2018-04-27 13:44 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, Eric Dumazet, netdev; +Cc: cake, Dave Taht
In-Reply-To: <87in8c4vn7.fsf@toke.dk>
On 04/27/2018 06:38 AM, Toke Høiland-Jørgensen wrote:
>
> Ah, right. Will fix.
>
> Is it safe to dereference the iph pointer before calling
> pskb_may_pull()?
No, please take a look at ip_rcv() for a typical use case.
^ permalink raw reply
* Re: [PATCH net-next v2 4/7] net: mscc: Add initial Ocelot switch support
From: Alexandre Belloni @ 2018-04-27 13:44 UTC (permalink / raw)
To: Andrew Lunn
Cc: David S . Miller, Allan Nielsen, razvan.stefanescu, po.liu,
Thomas Petazzoni, Florian Fainelli, netdev, devicetree,
linux-kernel, linux-mips
In-Reply-To: <20180426210915.GE23481@lunn.ch>
On 26/04/2018 23:09:15+0200, Andrew Lunn wrote:
> > +/* Checks if the net_device instance given to us originate from our driver. */
> > +static bool ocelot_netdevice_dev_check(const struct net_device *dev)
> > +{
> > + return dev->netdev_ops == &ocelot_port_netdev_ops;
> > +}
>
> This is probably O.K. now, but when you add support for controlling
> the switch over PCIe, i think it breaks. A board could have two
> switches...
>
> It might be possible to do something with dev->parent. All ports of a
> switch should have the same parent.
>
Actually, that is fine because it simply ensures netdev_priv(dev); is a
struct ocelot_port.
Later on, we get ocelot_port->ocelot and do the right thing.
The only thing that would not be working when having multiple of those
switches on the same platform would be having interfaces from different
switches in the same bridge. Anyway, this is definitively not something
we want because of the limited bandwidth of the CPU port.
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH net-next v4] Add Common Applications Kept Enhanced (cake) qdisc
From: Toke Høiland-Jørgensen @ 2018-04-27 13:38 UTC (permalink / raw)
To: Eric Dumazet, netdev; +Cc: cake, Dave Taht
In-Reply-To: <efb401ac-bc79-cbc5-cd03-120803b65b4d@gmail.com>
Eric Dumazet <eric.dumazet@gmail.com> writes:
> On 04/27/2018 05:17 AM, Toke Høiland-Jørgensen wrote:
>
> ...
>
>> +
>> +static struct sk_buff *cake_ack_filter(struct cake_sched_data *q,
>> + struct cake_flow *flow)
>> +{
>> + int seglen;
>> + struct sk_buff *skb = flow->tail, *skb_check, *skb_check_prev;
>> + struct iphdr *iph, *iph_check;
>> + struct ipv6hdr *ipv6h, *ipv6h_check;
>> + struct tcphdr *tcph, *tcph_check;
>> + bool otherconn_ack_seen = false;
>> + struct sk_buff *otherconn_checked_to = NULL;
>> + bool thisconn_redundant_seen = false, thisconn_seen_last = false;
>> + struct sk_buff *thisconn_checked_to = NULL, *thisconn_ack = NULL;
>> + bool aggressive = q->ack_filter == CAKE_ACK_AGGRESSIVE;
>> +
>> + /* no other possible ACKs to filter */
>> + if (flow->head == skb)
>> + return NULL;
>> +
>> + iph = skb->encapsulation ? inner_ip_hdr(skb) : ip_hdr(skb);
>> + ipv6h = skb->encapsulation ? inner_ipv6_hdr(skb) : ipv6_hdr(skb);
>> +
>> + /* check that the innermost network header is v4/v6, and contains TCP */
>> + if (pskb_may_pull(skb, ((unsigned char *)iph - skb->head) + sizeof(struct iphdr)) &&
>> + iph->version == 4) {
>> + if (iph->protocol != IPPROTO_TCP)
>> + return NULL;
>> + seglen = ntohs(iph->tot_len) - (4 * iph->ihl);
>> + tcph = (struct tcphdr *)((void *)iph + (4 * iph->ihl));
>> + if (!pskb_may_pull(skb, ((unsigned char *)tcph - skb->head) + sizeof(struct tcphdr)))
>> + return NULL;
>> + } else if (pskb_may_pull(skb, ((unsigned char *)ipv6h - skb->head) + sizeof(struct ipv6hdr) + sizeof(struct tcphdr)) &&
>> + ipv6h->version == 6) {
>> + if (ipv6h->nexthdr != IPPROTO_TCP)
>> + return NULL;
>> + seglen = ntohs(ipv6h->payload_len);
>> + tcph = (struct tcphdr *)((void *)ipv6h +
>> + sizeof(struct ipv6hdr));
>> + } else {
>> + return NULL;
>> + }
>> +
>
>
> This is still broken.
>
> After pskb_may_pull(), skb->head might have been reallocated.
>
> You need to recompute iph , ipv6h, tcph, otherwise you are reading
> freed memory and crash kernels with sufficient debugging (KASAN and
> other CONFIG_DEBUG_PAGEALLOC / CONFIG_DEBUG_SLAB like options)
Ah, right. Will fix.
Is it safe to dereference the iph pointer before calling
pskb_may_pull()?
-Toke
^ permalink raw reply
* Re: [PATCH] ptp_pch: use helpers function for converting between ns and timespec
From: Richard Cochran @ 2018-04-27 13:26 UTC (permalink / raw)
To: YueHaibing; +Cc: davem, netdev, linux-kernel
In-Reply-To: <20180427073618.12036-1-yuehaibing@huawei.com>
On Fri, Apr 27, 2018 at 03:36:18PM +0800, YueHaibing wrote:
> use ns_to_timespec64() and timespec64_to_ns() instead of open coding
Acked-by: Richard Cochran <richardcochran@gmail.com>
^ permalink raw reply
* Re: [PATCH net-next v4] Add Common Applications Kept Enhanced (cake) qdisc
From: Eric Dumazet @ 2018-04-27 13:17 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, netdev; +Cc: cake, Dave Taht
In-Reply-To: <20180427121706.23273-1-toke@toke.dk>
On 04/27/2018 05:17 AM, Toke Høiland-Jørgensen wrote:
...
> +
> +static struct sk_buff *cake_ack_filter(struct cake_sched_data *q,
> + struct cake_flow *flow)
> +{
> + int seglen;
> + struct sk_buff *skb = flow->tail, *skb_check, *skb_check_prev;
> + struct iphdr *iph, *iph_check;
> + struct ipv6hdr *ipv6h, *ipv6h_check;
> + struct tcphdr *tcph, *tcph_check;
> + bool otherconn_ack_seen = false;
> + struct sk_buff *otherconn_checked_to = NULL;
> + bool thisconn_redundant_seen = false, thisconn_seen_last = false;
> + struct sk_buff *thisconn_checked_to = NULL, *thisconn_ack = NULL;
> + bool aggressive = q->ack_filter == CAKE_ACK_AGGRESSIVE;
> +
> + /* no other possible ACKs to filter */
> + if (flow->head == skb)
> + return NULL;
> +
> + iph = skb->encapsulation ? inner_ip_hdr(skb) : ip_hdr(skb);
> + ipv6h = skb->encapsulation ? inner_ipv6_hdr(skb) : ipv6_hdr(skb);
> +
> + /* check that the innermost network header is v4/v6, and contains TCP */
> + if (pskb_may_pull(skb, ((unsigned char *)iph - skb->head) + sizeof(struct iphdr)) &&
> + iph->version == 4) {
> + if (iph->protocol != IPPROTO_TCP)
> + return NULL;
> + seglen = ntohs(iph->tot_len) - (4 * iph->ihl);
> + tcph = (struct tcphdr *)((void *)iph + (4 * iph->ihl));
> + if (!pskb_may_pull(skb, ((unsigned char *)tcph - skb->head) + sizeof(struct tcphdr)))
> + return NULL;
> + } else if (pskb_may_pull(skb, ((unsigned char *)ipv6h - skb->head) + sizeof(struct ipv6hdr) + sizeof(struct tcphdr)) &&
> + ipv6h->version == 6) {
> + if (ipv6h->nexthdr != IPPROTO_TCP)
> + return NULL;
> + seglen = ntohs(ipv6h->payload_len);
> + tcph = (struct tcphdr *)((void *)ipv6h +
> + sizeof(struct ipv6hdr));
> + } else {
> + return NULL;
> + }
> +
This is still broken.
After pskb_may_pull(), skb->head might have been reallocated.
You need to recompute iph , ipv6h, tcph, otherwise you are reading freed memory and crash kernels
with sufficient debugging (KASAN and other CONFIG_DEBUG_PAGEALLOC / CONFIG_DEBUG_SLAB like options)
^ permalink raw reply
* Re: [PATCH v2 net-next 1/2] tcp: add TCP_ZEROCOPY_RECEIVE support for zerocopy receive
From: Eric Dumazet @ 2018-04-27 13:03 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, David Miller, netdev, Andy Lutomirski, LKML, linux-mm,
Eric Dumazet, Soheil Hassas Yeganeh
In-Reply-To: <201804271455.cJQuTeDc%fengguang.wu@intel.com>
On Fri, Apr 27, 2018 at 1:45 AM kbuild test robot <lkp@intel.com> wrote:
> Hi Eric,
> Thank you for the patch! Yet something to improve:
> [auto build test ERROR on net-next/master]
> url:
https://github.com/0day-ci/linux/commits/Eric-Dumazet/tcp-add-TCP_ZEROCOPY_RECEIVE-support-for-zerocopy-receive/20180427-122234
> config: sh-rsk7269_defconfig (attached as .config)
> compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
> wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=sh
> All errors (new ones prefixed by >>):
> net/ipv4/tcp.o: In function `tcp_setsockopt':
> >> tcp.c:(.text+0x3f80): undefined reference to `zap_page_range'
I guess this tcp zerocopy stuff depends on CONFIG_MMU
Thanks.
^ permalink raw reply
* [PATCHv2 net] bridge: check iface upper dev when setting master via ioctl
From: Hangbin Liu @ 2018-04-27 12:59 UTC (permalink / raw)
To: netdev
Cc: Nikolay Aleksandrov, Dmitry Vyukov, syzbot, David Miller,
Hangbin Liu
In-Reply-To: <1524750986-23904-1-git-send-email-liuhangbin@gmail.com>
When we set a bond slave's master to bridge via ioctl, we only check
the IFF_BRIDGE_PORT flag. Although we will find the slave's real master
at netdev_master_upper_dev_link() later, it already does some settings
and allocates some resources. It would be better to return as early
as possible.
v1 -> v2:
use netdev_master_upper_dev_get() instead of netdev_has_any_upper_dev()
to check if we have a master, because not all upper devs are masters,
e.g. vlan device.
Reported-by: syzbot+de73361ee4971b6e6f75@syzkaller.appspotmail.com
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
net/bridge/br_if.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
index 82c1a6f..5bb6681 100644
--- a/net/bridge/br_if.c
+++ b/net/bridge/br_if.c
@@ -518,8 +518,8 @@ int br_add_if(struct net_bridge *br, struct net_device *dev,
return -ELOOP;
}
- /* Device is already being bridged */
- if (br_port_exists(dev))
+ /* Device has master upper dev */
+ if (netdev_master_upper_dev_get(dev))
return -EBUSY;
/* No bridging devices that dislike that (e.g. wireless) */
--
2.5.5
^ permalink raw reply related
* Hello from Lisa
From: Lisa Johnson @ 2018-04-27 12:44 UTC (permalink / raw)
Hello dear,
I am Miss Lisa. I have very important thing to discuss with you
please, this information is very vital. Contact me with my private
email so we can talk (lisajohnsonsalimanto@hotmail.com )
Lisa.
^ 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