* [PATCH bpf-next 1/6] bpf: rename stack trace map operations
From: Mauricio Vasquez B @ 2018-10-08 19:10 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, netdev
In-Reply-To: <153902585010.8888.3721528971287033661.stgit@kernel>
In the following patches queue and stack maps (FIFO and LIFO
datastructures) will be implemented. In order to avoid confusion and
a possible name clash rename stack_map_ops to stack_trace_map_ops
Signed-off-by: Mauricio Vasquez B <mauricio.vasquez@polito.it>
---
include/linux/bpf_types.h | 2 +-
kernel/bpf/stackmap.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/bpf_types.h b/include/linux/bpf_types.h
index 5432f4c9f50e..658509daacd4 100644
--- a/include/linux/bpf_types.h
+++ b/include/linux/bpf_types.h
@@ -51,7 +51,7 @@ BPF_MAP_TYPE(BPF_MAP_TYPE_LRU_HASH, htab_lru_map_ops)
BPF_MAP_TYPE(BPF_MAP_TYPE_LRU_PERCPU_HASH, htab_lru_percpu_map_ops)
BPF_MAP_TYPE(BPF_MAP_TYPE_LPM_TRIE, trie_map_ops)
#ifdef CONFIG_PERF_EVENTS
-BPF_MAP_TYPE(BPF_MAP_TYPE_STACK_TRACE, stack_map_ops)
+BPF_MAP_TYPE(BPF_MAP_TYPE_STACK_TRACE, stack_trace_map_ops)
#endif
BPF_MAP_TYPE(BPF_MAP_TYPE_ARRAY_OF_MAPS, array_of_maps_map_ops)
BPF_MAP_TYPE(BPF_MAP_TYPE_HASH_OF_MAPS, htab_of_maps_map_ops)
diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
index 8061a439ef18..bb41e293418d 100644
--- a/kernel/bpf/stackmap.c
+++ b/kernel/bpf/stackmap.c
@@ -600,7 +600,7 @@ static void stack_map_free(struct bpf_map *map)
put_callchain_buffers();
}
-const struct bpf_map_ops stack_map_ops = {
+const struct bpf_map_ops stack_trace_map_ops = {
.map_alloc = stack_map_alloc,
.map_free = stack_map_free,
.map_get_next_key = stack_map_get_next_key,
^ permalink raw reply related
* Re: BUG: corrupted list in p9_read_work
From: Dominique Martinet @ 2018-10-09 2:09 UTC (permalink / raw)
To: syzbot
Cc: davem, ericvh, linux-kernel, lucho, netdev, rminnich,
syzkaller-bugs, v9fs-developer
In-Reply-To: <000000000000fddb150577c15af6@google.com>
syzbot wrote on Mon, Oct 08, 2018:
> syzbot has found a reproducer for the following crash on:
>
> HEAD commit: 0854ba5ff5c9 Merge git://git.kernel.org/pub/scm/linux/kern..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1514ec06400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=88e9a8a39dc0be2d
> dashboard link: https://syzkaller.appspot.com/bug?extid=2222c34dc40b515f30dc
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10b91685400000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+2222c34dc40b515f30dc@syzkaller.appspotmail.com
>
> list_del corruption, ffff88019ae36ee8->next is LIST_POISON1
> (dead000000000100)
> ------------[ cut here ]------------
> [...]
> list_del include/linux/list.h:125 [inline]
> p9_read_work+0xab6/0x10e0 net/9p/trans_fd.c:379
Hmm this looks very much like the report from
syzbot+735d926e9d1317c3310c@syzkaller.appspotmail.com
which should have been fixed by Tomas in 9f476d7c540cb
("net/9p/trans_fd.c: fix race by holding the lock")...
It looks like another double list_del, looking at the code again there
actually are other ways this could happen around connection errors.
For example,
- p9_read_work receives something and lookup works... meanwhile
- p9_write_work fails to write and calls p9_conn_cancel, which deletes
from the req_list without waiting for other works to finish (could also
happen in p9_poll_mux)
- p9_read_work finishes processing the read and deletes from list again
For this one the simplest fix would probably be to just not
list_del/call p9_client_cb at all if m->r?req->status isn't
REQ_STATUS_ERROR in p9_read_work after the "got new packet" debug print,
and frankly I think that's saner so I'll send a patch shortly doing
that, but I have zero confidence there aren't similar bugs around, the
tcp code is so messy... Most of the syzbot reports recently have been
around trans_fd which I don't think is used much in real life, and this
is not really motivating (i.e. I think it would probably need a more
extensive rewrite but nobody cares) :/
Dmitry, on that note, do you think syzbot could possibly test other
transports somehow? rdma or virtio cannot be faked as easily as passing
a fd around, but I'd be very interested in seeing these flayed a bit.
(I'm also curious what logic is used to generate the syz tests, the
write$P9_Rxx replies have nothing to do with what the client would
expect so it probably doesn't test very far; this test in particular
does not even get past the initial P9_TVERSION that the client would
expect immediately after mount, so it's basically only testing logic
around packet handling on error... Or if we're accepting a RREADDIR in
reply to TVERSION we have bigger problems, and now I'm looking at it I
think we just might never check that....... I'll look at that for the
next cycle)
Back to the current patch, since as I said I am not confident this is a
good enough fix for the current bug, will I get notified if the bug
happens again once the patch hits linux-next with the Reported-by tag ?
(I don't have the setup necessary to run a syz repro as there is no C
repro, and won't have much time to do that setup sorry)
> FS-Cache: N-cookie d=000000000a092700 n=00000000d8ee0022
> FS-Cache: N-key=[10] '34323935303034313132'
> FS-Cache: Duplicate cookie detected
> FS-Cache: O-cookie c=00000000911358e4 [p=000000006545c95d fl=222 nc=0 na=1]
> FS-Cache: O-cookie d=000000000a092700 n=000000007635356b
> FS-Cache: O-key=[10] '
> [...]
(on an unrelated topic, I got these FS-Cache warnings quite often when
testing with cache enabled and have no idea what they mean. I don't
normally use cache so haven't spent time looking at it, but I find these
rather worrying... If someone having a clue reads this, I'd love to hear
what they could mean and what we should look at)
Thanks,
--
Dominique
^ permalink raw reply
* [PATCH net-next V3] virtio_net: ethtool tx napi configuration
From: Jason Wang @ 2018-10-09 2:06 UTC (permalink / raw)
To: mst, jasowang, davem
Cc: netdev, Willem de Bruijn, linux-kernel, virtualization
Implement ethtool .set_coalesce (-C) and .get_coalesce (-c) handlers.
Interrupt moderation is currently not supported, so these accept and
display the default settings of 0 usec and 1 frame.
Toggle tx napi through setting tx-frames. So as to not interfere
with possible future interrupt moderation, value 1 means tx napi while
value 0 means not.
Only allow the switching when device is down for simplicity.
Link: https://patchwork.ozlabs.org/patch/948149/
Suggested-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
Changes from V2:
- only allow the switching when device is done
- remove unnecessary global variable and initialization
Changes from V1:
- try to synchronize with datapath to allow changing mode when
interface is up.
- use tx-frames 0 as to disable tx napi while tx-frames 1 to enable tx napi
---
drivers/net/virtio_net.c | 50 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 50 insertions(+)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 765920905226..751f385f4e0a 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -2181,6 +2181,54 @@ static int virtnet_get_link_ksettings(struct net_device *dev,
return 0;
}
+static int virtnet_set_coalesce(struct net_device *dev,
+ struct ethtool_coalesce *ec)
+{
+ struct ethtool_coalesce ec_default = {
+ .cmd = ETHTOOL_SCOALESCE,
+ .rx_max_coalesced_frames = 1,
+ };
+ struct virtnet_info *vi = netdev_priv(dev);
+ int i, napi_weight;
+ bool running = netif_running(dev);
+
+ if (ec->tx_max_coalesced_frames > 1)
+ return -EINVAL;
+
+ ec_default.tx_max_coalesced_frames = ec->tx_max_coalesced_frames;
+ napi_weight = ec->tx_max_coalesced_frames ? NAPI_POLL_WEIGHT : 0;
+
+ /* disallow changes to fields not explicitly tested above */
+ if (memcmp(ec, &ec_default, sizeof(ec_default)))
+ return -EINVAL;
+
+ if (napi_weight ^ vi->sq[0].napi.weight) {
+ if (dev->flags & IFF_UP)
+ return -EBUSY;
+ for (i = 0; i < vi->max_queue_pairs; i++)
+ vi->sq[i].napi.weight = napi_weight;
+ }
+
+ return 0;
+}
+
+static int virtnet_get_coalesce(struct net_device *dev,
+ struct ethtool_coalesce *ec)
+{
+ struct ethtool_coalesce ec_default = {
+ .cmd = ETHTOOL_GCOALESCE,
+ .rx_max_coalesced_frames = 1,
+ };
+ struct virtnet_info *vi = netdev_priv(dev);
+
+ memcpy(ec, &ec_default, sizeof(ec_default));
+
+ if (vi->sq[0].napi.weight)
+ ec->tx_max_coalesced_frames = 1;
+
+ return 0;
+}
+
static void virtnet_init_settings(struct net_device *dev)
{
struct virtnet_info *vi = netdev_priv(dev);
@@ -2219,6 +2267,8 @@ static const struct ethtool_ops virtnet_ethtool_ops = {
.get_ts_info = ethtool_op_get_ts_info,
.get_link_ksettings = virtnet_get_link_ksettings,
.set_link_ksettings = virtnet_set_link_ksettings,
+ .set_coalesce = virtnet_set_coalesce,
+ .get_coalesce = virtnet_get_coalesce,
};
static void virtnet_freeze_down(struct virtio_device *vdev)
--
2.17.1
^ permalink raw reply related
* [PATCH net-next 3/3] selftests: mlxsw: qos_mc_aware: Make executable
From: Ido Schimmel @ 2018-10-08 18:50 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, Jiri Pirko, Petr Machata, Nir Dotan,
Ido Schimmel
In-Reply-To: <20181008184945.788-1-idosch@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
This is a self-standing test and as such should be itself executable.
Fixes: b5638d46c90a ("selftests: mlxsw: Add a test for UC behavior under MC flood")
Signed-off-by: Petr Machata <petrm@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
tools/testing/selftests/drivers/net/mlxsw/qos_mc_aware.sh | 0
1 file changed, 0 insertions(+), 0 deletions(-)
mode change 100644 => 100755 tools/testing/selftests/drivers/net/mlxsw/qos_mc_aware.sh
diff --git a/tools/testing/selftests/drivers/net/mlxsw/qos_mc_aware.sh b/tools/testing/selftests/drivers/net/mlxsw/qos_mc_aware.sh
old mode 100644
new mode 100755
--
2.17.1
^ permalink raw reply
* [PATCH net-next 2/3] selftests: forwarding: Have lldpad_app_wait_set() wait for unknown, too
From: Ido Schimmel @ 2018-10-08 18:50 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, Jiri Pirko, Petr Machata, Nir Dotan,
Ido Schimmel
In-Reply-To: <20181008184945.788-1-idosch@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
Immediately after mlxsw module is probed and lldpad started, added APP
entries are briefly in "unknown" state before becoming "pending". That's
the state that lldpad_app_wait_set() typically sees, and since there are
no pending entries at that time, it bails out. However the entries have
not been pushed to the kernel yet at that point, and thus the test case
fails.
Fix by waiting for both unknown and pending entries to disappear before
proceeding.
Fixes: d159261f3662 ("selftests: mlxsw: Add test for trust-DSCP")
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
tools/testing/selftests/net/forwarding/lib.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/net/forwarding/lib.sh b/tools/testing/selftests/net/forwarding/lib.sh
index 0e73698b2048..85d253546684 100644
--- a/tools/testing/selftests/net/forwarding/lib.sh
+++ b/tools/testing/selftests/net/forwarding/lib.sh
@@ -251,7 +251,7 @@ lldpad_app_wait_set()
{
local dev=$1; shift
- while lldptool -t -i $dev -V APP -c app | grep -q pending; do
+ while lldptool -t -i $dev -V APP -c app | grep -Eq "pending|unknown"; do
echo "$dev: waiting for lldpad to push pending APP updates"
sleep 5
done
--
2.17.1
^ permalink raw reply related
* [PATCH net-next 1/3] mlxsw: pci: Fix a typo
From: Ido Schimmel @ 2018-10-08 18:50 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, Jiri Pirko, Petr Machata, Nir Dotan,
Ido Schimmel
In-Reply-To: <20181008184945.788-1-idosch@mellanox.com>
From: Nir Dotan <nird@mellanox.com>
Signed-off-by: Nir Dotan <nird@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/pci_hw.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/pci_hw.h b/drivers/net/ethernet/mellanox/mlxsw/pci_hw.h
index 83f452b7ccbb..bb99f6d41fe0 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/pci_hw.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/pci_hw.h
@@ -221,7 +221,7 @@ MLXSW_ITEM32(pci, eqe, event_type, 0x0C, 24, 8);
MLXSW_ITEM32(pci, eqe, event_sub_type, 0x0C, 16, 8);
/* pci_eqe_cqn
- * Completion Queue that triggeret this EQE.
+ * Completion Queue that triggered this EQE.
*/
MLXSW_ITEM32(pci, eqe, cqn, 0x0C, 8, 7);
--
2.17.1
^ permalink raw reply related
* [PATCH net-next 0/3] mlxsw: selftests: Few small updates
From: Ido Schimmel @ 2018-10-08 18:50 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, Jiri Pirko, Petr Machata, Nir Dotan,
Ido Schimmel
First patch fixes a typo in mlxsw.
Second patch fixes a race in a recent test.
Third patch makes a recent test executable.
Nir Dotan (1):
mlxsw: pci: Fix a typo
Petr Machata (2):
selftests: forwarding: Have lldpad_app_wait_set() wait for unknown,
too
selftests: mlxsw: qos_mc_aware: Make executable
drivers/net/ethernet/mellanox/mlxsw/pci_hw.h | 2 +-
tools/testing/selftests/drivers/net/mlxsw/qos_mc_aware.sh | 0
tools/testing/selftests/net/forwarding/lib.sh | 2 +-
3 files changed, 2 insertions(+), 2 deletions(-)
mode change 100644 => 100755 tools/testing/selftests/drivers/net/mlxsw/qos_mc_aware.sh
--
2.17.1
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH][-next] ixgbe: don't clear_bit on xdp_ring->state if xdp_ring is null
From: Bowers, AndrewX @ 2018-10-08 18:38 UTC (permalink / raw)
To: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org
In-Reply-To: <20181004175732.28329-1-colin.king@canonical.com>
> -----Original Message-----
> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@osuosl.org] On
> Behalf Of Colin King
> Sent: Thursday, October 4, 2018 10:58 AM
> To: Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com>; David S . Miller
> <davem@davemloft.net>; intel-wired-lan@lists.osuosl.org;
> netdev@vger.kernel.org
> Cc: kernel-janitors@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH][-next] ixgbe: don't clear_bit on xdp_ring-
> >state if xdp_ring is null
>
> From: Colin Ian King <colin.king@canonical.com>
>
> There is an earlier check to see if xdp_ring is null when configuring the tx ring,
> so assuming that it can still be null, the clearing of the xdp_ring->state
> currently could end up with a null pointer dereference. Fix this by only
> clearing the bit if xdp_ring is not null.
>
> Detected by CoverityScan, CID#1473795 ("Dereference after null check")
>
> Fixes: 024aa5800f32 ("ixgbe: added Rx/Tx ring disable/enable functions")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
^ permalink raw reply
* [PATCH v2] mt76x0: pci: fix set external PA I/O current
From: YueHaibing @ 2018-10-09 1:45 UTC (permalink / raw)
To: Kalle Valo, Felix Fietkau, Lorenzo Bianconi, Stanislaw Gruszka
Cc: YueHaibing, linux-wireless, kernel-janitors, netdev, linux-kernel
In-Reply-To: <1539004909-195005-1-git-send-email-yuehaibing@huawei.com>
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/mediatek/mt76/mt76x0/pci.c: In function 'mt76x0e_register_device':
drivers/net/wireless/mediatek/mt76/mt76x0/pci.c:107:8: warning:
variable 'data' set but not used [-Wunused-but-set-variable]
It seems correct value to write is 'data'
Fixes: 2b2cb40bcd7d ("mt76x0: pci: add hw initialization at bootstrap")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
---
v2: remove 'net-next' from patch title
---
drivers/net/wireless/mediatek/mt76/mt76x0/pci.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c b/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
index 87997cd..0426c68 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
@@ -106,12 +106,12 @@ static int mt76x0e_register_device(struct mt76x02_dev *dev)
if (val & MT_EE_NIC_CONF_0_PA_IO_CURRENT) {
u32 data;
- /* set external external PA I/O
+ /* set external PA I/O
* current to 16mA
*/
data = mt76_rr(dev, 0x11c);
- val |= 0xc03;
- mt76_wr(dev, 0x11c, val);
+ data |= 0xc03;
+ mt76_wr(dev, 0x11c, data);
}
}
^ permalink raw reply related
* Re: skb length without fragments
From: Eric Dumazet @ 2018-10-08 18:23 UTC (permalink / raw)
To: pradeep kumar nalla, netdev
In-Reply-To: <CAABr=eaZePxgwS=0fFhUMsXxd1T0PbcQ4-TJBOw4z4qqhEN_cA@mail.gmail.com>
On 10/08/2018 11:02 AM, pradeep kumar nalla wrote:
> Hi
>
> While testing my network driver with pktgen I could see an skb greater
> than 16K without fragments in xmit function. This lead to a fix in my
> driver that assumes when an SKB whose length is greater than 16K will
> come with fragments. Apart from pktgen what are the chances or
> possibilities of getting an SKB greater than 16K without fragments? .
> When I tried with tools like iperf/iper3/netperf, didn’t see a single
> incidence where the SKB length is greater than 16K and without frags.
> Even socket layer I see function alloc_skb_with_frags, does this mean
> all the larger packets come with frags.
>
There are cases where skb_linearize() calls happen, and then certainly
can feed a driver with a big linear skb.
Even if current tree would not hit this, you have to play safe and
do the check in the driver.
^ permalink raw reply
* Re: [PATCH net-next] net/ipv6: stop leaking percpu memory in fib6 info
From: David Ahern @ 2018-10-08 18:15 UTC (permalink / raw)
To: Mike Rapoport, David S. Miller; +Cc: netdev, stable
In-Reply-To: <1539000363-25333-1-git-send-email-rppt@linux.vnet.ibm.com>
On 10/8/18 6:06 AM, Mike Rapoport wrote:
> The fib6_info_alloc() function allocates percpu memory to hold per CPU
> pointers to rt6_info, but this memory is never freed. Fix it.
>
> Fixes: a64efe142f5e ("net/ipv6: introduce fib6_info struct and helpers")
>
> Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
> Cc: stable@vger.kernel.org
> ---
> net/ipv6/ip6_fib.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c
> index cf709eadc932..cc7de7eb8b9c 100644
> --- a/net/ipv6/ip6_fib.c
> +++ b/net/ipv6/ip6_fib.c
> @@ -194,6 +194,8 @@ void fib6_info_destroy_rcu(struct rcu_head *head)
> *ppcpu_rt = NULL;
> }
> }
> +
> + free_percpu(f6i->rt6i_pcpu);
> }
>
> lwtstate_put(f6i->fib6_nh.nh_lwtstate);
>
Odd that KMEMLEAK is not detecting this. Thanks for the fix.
Reviewed-by: David Ahern <dsahern@gmail.com>
^ permalink raw reply
* [PATCH v2 ipsec] Clear secpath on loopback_xmit
From: Benedict Wong @ 2018-10-08 18:13 UTC (permalink / raw)
To: netdev; +Cc: nharold, benedictwong, lorenzo
This patch clears the skb->sp when transmitted over loopback. This
ensures that the loopback-ed packet does not have any secpath
information from the outbound transforms.
At present, this causes XFRM tunnel mode packets to be dropped with
XFRMINNOPOLS, due to the outbound state being in the secpath, without
a matching inbound policy. Clearing the secpath ensures that all states
added to the secpath are exclusively from the inbound processing.
Tests: xfrm tunnel mode tests added for loopback:
https://android-review.googlesource.com/c/kernel/tests/+/777328
Fixes: 8fe7ee2ba983 ("[IPsec]: Strengthen policy checks")
Signed-off-by: Benedict Wong <benedictwong@google.com>
---
drivers/net/loopback.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/loopback.c b/drivers/net/loopback.c
index 30612497643c..a6bf54df94bd 100644
--- a/drivers/net/loopback.c
+++ b/drivers/net/loopback.c
@@ -50,6 +50,7 @@
#include <linux/ethtool.h>
#include <net/sock.h>
#include <net/checksum.h>
+#include <net/xfrm.h>
#include <linux/if_ether.h> /* For the statistics structure. */
#include <linux/if_arp.h> /* For ARPHRD_ETHER */
#include <linux/ip.h>
@@ -82,6 +83,9 @@ static netdev_tx_t loopback_xmit(struct sk_buff *skb,
*/
skb_dst_force(skb);
+ // Clear secpath to ensure xfrm policy check not tainted by outbound SAs.
+ secpath_reset(skb);
+
skb->protocol = eth_type_trans(skb, dev);
/* it's OK to use per_cpu_ptr() because BHs are off */
--
2.19.0.605.g01d371f741-goog
^ permalink raw reply related
* Re: [PATCH net-next] mt76x0: pci: fix set external PA I/O current
From: YueHaibing @ 2018-10-09 1:24 UTC (permalink / raw)
To: David Miller
Cc: kvalo, nbd, lorenzo.bianconi, sgruszka, linux-wireless,
kernel-janitors, netdev, linux-kernel
In-Reply-To: <20181008.110230.1232459474222849074.davem@davemloft.net>
On 2018/10/9 2:02, David Miller wrote:
> From: YueHaibing <yuehaibing@huawei.com>
> Date: Mon, 8 Oct 2018 13:21:49 +0000
>
>> Fixes gcc '-Wunused-but-set-variable' warning:
>>
>> drivers/net/wireless/mediatek/mt76/mt76x0/pci.c: In function 'mt76x0e_register_device':
>> drivers/net/wireless/mediatek/mt76/mt76x0/pci.c:107:8: warning:
>> variable 'data' set but not used [-Wunused-but-set-variable]
>>
>> It seems correct value to write is 'data'
>>
>> Fixes: 2b2cb40bcd7d ("mt76x0: pci: add hw initialization at bootstrap")
>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
>
> Wireless changes should be marked as appropriate in the Subject line
> for targetting the wireless GIT tree, not "net-next".
Ok, will fix it in v2.
>
> .
>
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2018-10-09 1:21 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Al Viro,
Jamal Hadi Salim
[-- Attachment #1: Type: text/plain, Size: 836 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
net/sched/cls_u32.c
between commit:
6d4c407744dd ("net: sched: cls_u32: fix hnode refcounting")
from the net tree and commit:
a030598690c6 ("net: sched: cls_u32: simplify the hell out u32_delete() emptiness check")
from the net-next tree.
I fixed it up (I reverted the net tree commit as I could not tell
wich parts of it, if any, are still needed) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] dpaa2-eth: Don't account Tx confirmation frames on NAPI poll
From: David Miller @ 2018-10-08 18:05 UTC (permalink / raw)
To: ruxandra.radulescu; +Cc: netdev, ioana.ciornei
In-Reply-To: <1539008183-5288-1-git-send-email-ruxandra.radulescu@nxp.com>
From: Ioana Ciocoi Radulescu <ruxandra.radulescu@nxp.com>
Date: Mon, 8 Oct 2018 14:16:31 +0000
> Until now, both Rx and Tx confirmation frames handled during
> NAPI poll were counted toward the NAPI budget. However, Tx
> confirmations are lighter to process than Rx frames, which can
> skew the amount of work actually done inside one NAPI cycle.
>
> Update the code to only count Rx frames toward the NAPI budget
> and set a separate threshold on how many Tx conf frames can be
> processed in one poll cycle.
>
> The NAPI poll routine stops when either the budget is consumed
> by Rx frames or when Tx confirmation frames reach this threshold.
>
> Signed-off-by: Ioana Radulescu <ruxandra.radulescu@nxp.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: mscc: ocelot: remove set but not used variable 'phy_mode'
From: David Miller @ 2018-10-08 18:04 UTC (permalink / raw)
To: yuehaibing; +Cc: alexandre.belloni, netdev, kernel-janitors
In-Reply-To: <1539007670-82488-1-git-send-email-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Mon, 8 Oct 2018 14:07:50 +0000
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/ethernet/mscc/ocelot_board.c: In function 'mscc_ocelot_probe':
> drivers/net/ethernet/mscc/ocelot_board.c:262:17: warning:
> variable 'phy_mode' set but not used [-Wunused-but-set-variable]
> enum phy_mode phy_mode;
>
> It never used since introduction in
> commit 71e32a20cfbf ("net: mscc: ocelot: make use of SerDes PHYs for handling their configuration")
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 net-next 11/23] rtnetlink: Update rtnl_stats_dump for strict data checking
From: David Miller @ 2018-10-08 18:02 UTC (permalink / raw)
To: dsahern; +Cc: christian, dsahern, netdev, jbenc, stephen
In-Reply-To: <ddf7efb8-e7d6-fb6a-7b85-fe3c94819488@gmail.com>
From: David Ahern <dsahern@gmail.com>
Date: Mon, 8 Oct 2018 07:25:34 -0600
> On 10/8/18 4:17 AM, Christian Brauner wrote:
>>> @@ -4696,13 +4697,32 @@ static int rtnl_stats_dump(struct sk_buff *skb, struct netlink_callback *cb)
>>>
>>> cb->seq = net->dev_base_seq;
>>>
>>> - if (nlmsg_len(cb->nlh) < sizeof(*ifsm))
>>> + if (nlmsg_len(cb->nlh) < sizeof(*ifsm)) {
>>> + NL_SET_ERR_MSG(extack, "Invalid header for stats dump");
>>> return -EINVAL;
>>> + }
>>>
>>> ifsm = nlmsg_data(cb->nlh);
>>> +
>>> + /* only requests using NLM_F_DUMP_PROPER_HDR can pass data to
>>
>> That looks like an accidental leftover before we changed this to a
>> socket option. :)
>>
>
> ugh. thanks for noticing.
David, I applied this series, please send me relative fixups at this point
if necessary.
Thanks.
^ permalink raw reply
* skb length without fragments
From: pradeep kumar nalla @ 2018-10-08 18:02 UTC (permalink / raw)
To: netdev
Hi
While testing my network driver with pktgen I could see an skb greater
than 16K without fragments in xmit function. This lead to a fix in my
driver that assumes when an SKB whose length is greater than 16K will
come with fragments. Apart from pktgen what are the chances or
possibilities of getting an SKB greater than 16K without fragments? .
When I tried with tools like iperf/iper3/netperf, didn’t see a single
incidence where the SKB length is greater than 16K and without frags.
Even socket layer I see function alloc_skb_with_frags, does this mean
all the larger packets come with frags.
Please pardon if it is not a correct mailing list to ask above question.
Thanks
Pradeep.
^ permalink raw reply
* Re: [PATCH V1 net 0/5] minor bug fixes for ENA Ethernet driver
From: David Miller @ 2018-10-08 18:01 UTC (permalink / raw)
To: nafea
Cc: akiyano, netdev, dwmw, zorik, matua, saeedb, msw, aliguori,
gtzalik, netanel, alisaidi
In-Reply-To: <7BF68A50-AD04-4FA7-91ED-F3F6412E2E2E@amazon.com>
From: "Bshara, Nafea" <nafea@amazon.com>
Date: Mon, 8 Oct 2018 12:47:50 +0000
> Ship it
Anything but... see my feedback.
^ permalink raw reply
* Re: [PATCH net-next 0/3] selftests: add more PMTU tests
From: David Miller @ 2018-10-08 18:00 UTC (permalink / raw)
To: sd; +Cc: netdev, sbrivio
In-Reply-To: <cover.1539001627.git.sd@queasysnail.net>
From: Sabrina Dubroca <sd@queasysnail.net>
Date: Mon, 8 Oct 2018 14:37:02 +0200
> The current selftests for PMTU cover VTI tunnels, but there's nothing
> about the generation and handling of PMTU exceptions by intermediate
> routers. This series adds and improves existing helpers, then adds
> IPv4 and IPv6 selftests with a setup involving an intermediate router.
>
> Joint work with Stefano Brivio.
This is really great stuff to see.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net 1/2] net: ipv4: update fnhe_pmtu when first hop's MTU changes
From: David Miller @ 2018-10-08 17:58 UTC (permalink / raw)
To: sd; +Cc: netdev, sbrivio
In-Reply-To: <bdb0235df165b1a9684670be3839962c80c9b45a.1539000663.git.sd@queasysnail.net>
From: Sabrina Dubroca <sd@queasysnail.net>
Date: Mon, 8 Oct 2018 14:36:38 +0200
> Since commit 5aad1de5ea2c ("ipv4: use separate genid for next hop
> exceptions"), exceptions get deprecated separately from cached
> routes. In particular, administrative changes don't clear PMTU anymore.
>
> As Stefano described in commit e9fa1495d738 ("ipv6: Reflect MTU changes
> on PMTU of exceptions for MTU-less routes"), the PMTU discovered before
> the local MTU change can become stale:
> - if the local MTU is now lower than the PMTU, that PMTU is now
> incorrect
> - if the local MTU was the lowest value in the path, and is increased,
> we might discover a higher PMTU
>
> Similarly to what commit e9fa1495d738 did for IPv6, update PMTU in those
> cases.
>
> If the exception was locked, discovered the PMTU was smaller than the
> minimal accepted PMTU. In that case, if the new local MTU is smaller
> than the current PMTU, let PMTU discovery figure out if locking of the
> exception is still needed.
>
> To do this, we need to know the old link MTU in the NETDEV_CHANGEMTU
> notifier. By the time the notifier is called, dev->mtu has been
> changed. This patch adds the old MTU as additional information in the
> notifier structure, and a new call_netdevice_notifiers_u32() function.
>
> Fixes: 5aad1de5ea2c ("ipv4: use separate genid for next hop exceptions")
> Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
> Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
Please, when you respin this to address David Ahern's feedback, provide
a proper "0/N" header posting.
Thank you.
^ permalink raw reply
* Re: [PATCH V1 net 2/5] net: ena: fix warning in rmmod caused by double iounmap
From: David Miller @ 2018-10-08 17:56 UTC (permalink / raw)
To: akiyano
Cc: netdev, dwmw, zorik, matua, saeedb, msw, aliguori, nafea, gtzalik,
netanel, alisaidi
In-Reply-To: <1539001724-25980-3-git-send-email-akiyano@amazon.com>
From: <akiyano@amazon.com>
Date: Mon, 8 Oct 2018 15:28:41 +0300
> From: Arthur Kiyanovski <akiyano@amazon.com>
>
> Memory mapped with devm_ioremap is automatically freed when the driver
> is disconnected from the device. Therefore there is no need to
> explicitly call devm_iounmap.
>
> Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com>
> ---
> drivers/net/ethernet/amazon/ena/ena_netdev.c | 10 +---------
> 1 file changed, 1 insertion(+), 9 deletions(-)
>
> diff --git a/drivers/net/ethernet/amazon/ena/ena_netdev.c b/drivers/net/ethernet/amazon/ena/ena_netdev.c
> index 25621a2..23f2dda 100644
> --- a/drivers/net/ethernet/amazon/ena/ena_netdev.c
> +++ b/drivers/net/ethernet/amazon/ena/ena_netdev.c
> @@ -3099,15 +3099,7 @@ static int ena_rss_init_default(struct ena_adapter *adapter)
>
> static void ena_release_bars(struct ena_com_dev *ena_dev, struct pci_dev *pdev)
> {
> - int release_bars;
> -
> - if (ena_dev->mem_bar)
> - devm_iounmap(&pdev->dev, ena_dev->mem_bar);
> -
> - if (ena_dev->reg_bar)
> - devm_iounmap(&pdev->dev, ena_dev->reg_bar);
> -
> - release_bars = pci_select_bars(pdev, IORESOURCE_MEM) & ENA_BAR_MASK;
> + int release_bars = pci_select_bars(pdev, IORESOURCE_MEM) & ENA_BAR_MASK;
> pci_release_selected_regions(pdev, release_bars);
Always have an empty line between local variable declarations and actual
function code.
^ permalink raw reply
* Re: [PATCH V1 net 0/5] minor bug fixes for ENA Ethernet driver
From: David Miller @ 2018-10-08 17:56 UTC (permalink / raw)
To: akiyano
Cc: netdev, dwmw, zorik, matua, saeedb, msw, aliguori, nafea, gtzalik,
netanel, alisaidi
In-Reply-To: <1539001724-25980-1-git-send-email-akiyano@amazon.com>
From: <akiyano@amazon.com>
Date: Mon, 8 Oct 2018 15:28:39 +0300
> From: Arthur Kiyanovski <akiyano@amazon.com>
>
> Arthur Kiyanovski (5):
> net: ena: fix indentations in ena_defs for better readability
> net: ena: fix warning in rmmod caused by double iounmap
> net: ena: fix rare bug when failed restart/resume is followed by
> driver removal
> net: ena: fix NULL dereference due to untimely napi initialization
> net: ena: fix auto casting to boolean
Indentation fixes are not appropriate for a series of bug fixes. Separate
those out from the real legitimate bug fixes into a series for net-next.
^ permalink raw reply
* Re: [PATCH] bpf: btf: Fix a missing check bug
From: valdis.kletnieks @ 2018-10-09 1:07 UTC (permalink / raw)
To: Song Liu
Cc: wang6495, kjlu, Alexei Starovoitov, Daniel Borkmann, Networking,
open list
In-Reply-To: <CAPhsuW5nPGMOEMKa1UFwgquoUeYiUV8i8nVgWfM6McH2Ri1esg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1406 bytes --]
On Mon, 08 Oct 2018 17:44:46 -0700, Song Liu said:
> I think I get the security concept here. However, hdr_len here is only used to
> copy the whole header into kernel space, and it is not used in other
> logic at all.
> I cannot image any security flaw with either hdr_len > btf->hdr->hdr_len case or
> hdr_len < btf->hdr->hdr_len. Could you please provide more insights on what
> would break by malicious user space?
Say the biggest allowed value for hdr_len is 128. We check the value, the user has 98.
They then stuff 16,383 into there.
Now here's the problem - hdr_len is a local variable, and evaporates when the function
returns. From here on out, anybody who cares about the header length will use the
value in btf->hdr_len....
(And yes, somebody *does* care about the length, otherwise we wouldn't need a field
saying what the length was....)
Now think how many ways that can go pear-shaped. You copied in 98 bytes, but outside
the function, they think that header is almost 4 pages long. Does that ever get used as
a length for kmemcpy()? Or a limit for a 'for (i=start; i< (start+hdr->hdr_len); i++)' that
walks across a variable length header?
Can you cook up a way to have a good chance to oops the kernel when it walks off the
page you allocated the 98 bytes on? Can you use it to export chunks of memory out to
userspace? Lots and lots of ways for this to kersplat a kernel...;
[-- Attachment #2: Type: application/pgp-signature, Size: 486 bytes --]
^ permalink raw reply
* Re: [PATCH] dt-bindings: Add bindings for aliases node
From: Brian Norris @ 2018-10-09 1:07 UTC (permalink / raw)
To: Matthias Kaehlcke
Cc: Rob Herring, Mark Rutland, devicetree, linux-kernel,
linux-wireless, linux-spi, netdev, Stephen Boyd, Florian Fainelli
In-Reply-To: <20180925210255.172734-1-mka@chromium.org>
+ linux-spi, linux-wireless, netdev
+ others from previous conversations
Hi,
On Tue, Sep 25, 2018 at 02:02:55PM -0700, Matthias Kaehlcke wrote:
> Add a global binding for the 'aliases' node. This includes an initial list
> of standardized alias names for some hardware components that are commonly
> found in 'aliases'.
>
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> ---
> Documentation/devicetree/bindings/aliases.txt | 47 +++++++++++++++++++
> 1 file changed, 47 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/aliases.txt
>
> diff --git a/Documentation/devicetree/bindings/aliases.txt b/Documentation/devicetree/bindings/aliases.txt
> new file mode 100644
> index 000000000000..d64ed1c7eb34
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/aliases.txt
> @@ -0,0 +1,47 @@
> +The aliases node
> +----------------
I like the idea in general, and it might be good to note (e.g., commit
message) that this was inspired by this thread:
https://lore.kernel.org/lkml/20180815221601.GB24830@rob-hp-laptop/
where we were interested in firmware-to-device-tree path stability --
and the answer was basically: don't memorize paths, just use aliases
instead. But then, it was clear that aliases were not documented very
formally at all.
So here we are!
> +
> +The aliases node contains properties that represent aliases to device tree
> +nodes. The name of the property is the alias name, the value is the path of
> +a the device tree node that corresponds to the alias. The path may be
> +specified as a string or a phandle.
> +
> +Alias names are often suffixed with a numeric ID, especially when there may
> +be multiple instances of the same type. The ID typically corresponds to the
> +hardware layout, it may also be used by drivers for a stable mapping of
> +device names and hardware entities.
> +
> +Alias names
> +-----------
> +
> +The devicetree specification doesn't require the use of specific alias
> +names to refer to hardware entities of a given type, however the Linux
> +kernel aims for a certain level of consistency.
> +
> +The following standardized alias names shall be used for their
> +corresponding hardware components:
> +
> + bluetoothN Bluetooth controller
> + ethernetN Ethernet interface
> + gpioN GPIO controller
> + i2cN i2c bus
> + mmcN MMC bus
> + rtcN Real time clock
> + serialN UART port
> + spiN SPI bus
> + wifiN Wireless network interface
For the network-device-related names (bluetooth, ethernet, and wifi), I
think there's a clear documented reason for this (supporting MAC address
plumbing from a DT-aware bootloader). I'm not quite as sure about all
the others, and unfortunately, I'm aware of at least one subsystem owner
that explicitly does NOT like the aliases usage that is currently
supported (spi), and shot down a patch where I tried to use it in a DTS
file (despite its regular usage in many other DTS files).
So I guess I'm saying: perhaps we should get buy-in from various
subsystems before we include them? So maybe it's wiser to start
small(er) and only add once we're sure they are useful? Or perhaps Rob
has other thoughts.
> +
> +The above list is not exhaustive and will be extended over time. Please
> +send patches to devicetree@vger.kernel.org if you think a hardware
> +component and its alias name should be on the list.
> +
> +Example
> +-------
> +
> +aliases {
> + bluetooth0 = "/soc/serial@fdf01000/bluetooth";
> + rtc0 = &rtc0;
> + wifi0 = &wlcore;
> +};
> +
> +(based on arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts)
What is the relevance of this line? This doesn't look anything like that
hikey DTS. Maybe the "based on" line should just be removed? The example
seems fine though.
Anyway, perhaps with a trimmed list of supported alias names:
Reviewed-by: Brian Norris <briannorris@chromium.org>
^ 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