* [PATCH bpf-next 2/6] bpf/syscall: allow key to be null in map functions
From: Mauricio Vasquez B @ 2018-10-08 19:11 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, netdev
In-Reply-To: <153902585010.8888.3721528971287033661.stgit@kernel>
This commit adds the required logic to allow key being NULL
in case the key_size of the map is 0.
A new __bpf_copy_key function helper only copies the key from
userpsace when key_size != 0, otherwise it enforces that key must be
null.
Signed-off-by: Mauricio Vasquez B <mauricio.vasquez@polito.it>
---
kernel/bpf/syscall.c | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 5742df21598c..eb75e8af73ff 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -651,6 +651,17 @@ int __weak bpf_stackmap_copy(struct bpf_map *map, void *key, void *value)
return -ENOTSUPP;
}
+static void *__bpf_copy_key(void __user *ukey, u64 key_size)
+{
+ if (key_size)
+ return memdup_user(ukey, key_size);
+
+ if (ukey)
+ return ERR_PTR(-EINVAL);
+
+ return NULL;
+}
+
/* last field in 'union bpf_attr' used by this command */
#define BPF_MAP_LOOKUP_ELEM_LAST_FIELD value
@@ -678,7 +689,7 @@ static int map_lookup_elem(union bpf_attr *attr)
goto err_put;
}
- key = memdup_user(ukey, map->key_size);
+ key = __bpf_copy_key(ukey, map->key_size);
if (IS_ERR(key)) {
err = PTR_ERR(key);
goto err_put;
@@ -769,7 +780,7 @@ static int map_update_elem(union bpf_attr *attr)
goto err_put;
}
- key = memdup_user(ukey, map->key_size);
+ key = __bpf_copy_key(ukey, map->key_size);
if (IS_ERR(key)) {
err = PTR_ERR(key);
goto err_put;
@@ -871,7 +882,7 @@ static int map_delete_elem(union bpf_attr *attr)
goto err_put;
}
- key = memdup_user(ukey, map->key_size);
+ key = __bpf_copy_key(ukey, map->key_size);
if (IS_ERR(key)) {
err = PTR_ERR(key);
goto err_put;
@@ -923,7 +934,7 @@ static int map_get_next_key(union bpf_attr *attr)
}
if (ukey) {
- key = memdup_user(ukey, map->key_size);
+ key = __bpf_copy_key(ukey, map->key_size);
if (IS_ERR(key)) {
err = PTR_ERR(key);
goto err_put;
^ permalink raw reply related
* [PATCH bpf-next 0/6] Implement queue/stack maps
From: Mauricio Vasquez B @ 2018-10-08 19:10 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, netdev
In some applications this is needed have a pool of free elements, for
example the list of free L4 ports in a SNAT. None of the current maps allow
to do it as it is not possible to get any element without having they key
it is associated to, even if it were possible, the lack of locking mecanishms in
eBPF would do it almost impossible to be implemented without data races.
This patchset implements two new kind of eBPF maps: queue and stack.
Those maps provide to eBPF programs the peek, push and pop operations, and for
userspace applications a new bpf_map_lookup_and_delete_elem() is added.
Signed-off-by: Mauricio Vasquez B <mauricio.vasquez@polito.it>
RFC v4 -> v1:
- Remove roundup to power of 2 in memory allocation
- Remove count and use a free slot to check if queue/stack is empty
- Use if + assigment for wrapping indexes
- Fix some minor style issues
- Squash two patches together
RFC v3 -> RFC v4:
- Revert renaming of kernel/bpf/stackmap.c
- Remove restriction on value size
- Remove len arguments from peek/pop helpers
- Add new ARG_PTR_TO_UNINIT_MAP_VALUE
RFC v2 -> RFC v3:
- Return elements by value instead that by reference
- Implement queue/stack base on array and head + tail indexes
- Rename stack trace related files to avoid confusion and conflicts
RFC v1 -> RFC v2:
- Create two separate maps instead of single one + flags
- Implement bpf_map_lookup_and_delete syscall
- Support peek operation
- Define replacement policy through flags in the update() method
- Add eBPF side tests
---
Mauricio Vasquez B (6):
bpf: rename stack trace map operations
bpf/syscall: allow key to be null in map functions
bpf: add MAP_LOOKUP_AND_DELETE_ELEM syscall
bpf: add queue and stack maps
Sync uapi/bpf.h to tools/include
selftests/bpf: add test cases for queue and stack maps
include/linux/bpf.h | 8 +
include/linux/bpf_types.h | 4
include/uapi/linux/bpf.h | 36 ++-
kernel/bpf/Makefile | 2
kernel/bpf/core.c | 3
kernel/bpf/helpers.c | 43 +++
kernel/bpf/queue_stack_maps.c | 288 ++++++++++++++++++++
kernel/bpf/stackmap.c | 2
kernel/bpf/syscall.c | 112 ++++++++
kernel/bpf/verifier.c | 28 ++
net/core/filter.c | 6
tools/include/uapi/linux/bpf.h | 36 ++-
tools/lib/bpf/bpf.c | 12 +
tools/lib/bpf/bpf.h | 1
tools/testing/selftests/bpf/Makefile | 6
tools/testing/selftests/bpf/bpf_helpers.h | 7
tools/testing/selftests/bpf/test_maps.c | 122 ++++++++
tools/testing/selftests/bpf/test_progs.c | 99 +++++++
tools/testing/selftests/bpf/test_queue_map.c | 4
tools/testing/selftests/bpf/test_queue_stack_map.h | 59 ++++
tools/testing/selftests/bpf/test_stack_map.c | 4
21 files changed, 862 insertions(+), 20 deletions(-)
create mode 100644 kernel/bpf/queue_stack_maps.c
create mode 100644 tools/testing/selftests/bpf/test_queue_map.c
create mode 100644 tools/testing/selftests/bpf/test_queue_stack_map.h
create mode 100644 tools/testing/selftests/bpf/test_stack_map.c
^ permalink raw reply
* [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
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