* [PATCH bpf-next 2/4] tools: libbpf: add bpf_object__find_program_by_title()
From: Jakub Kicinski @ 2018-07-26 21:32 UTC (permalink / raw)
To: alexei.starovoitov, daniel; +Cc: oss-drivers, netdev, Jakub Kicinski
In-Reply-To: <20180726213221.1295-1-jakub.kicinski@netronome.com>
Allow users to find programs by section names.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
---
tools/lib/bpf/libbpf.c | 12 ++++++++++++
tools/lib/bpf/libbpf.h | 3 +++
2 files changed, 15 insertions(+)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index afa9860db755..857d3d16968e 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -873,6 +873,18 @@ bpf_object__find_prog_by_idx(struct bpf_object *obj, int idx)
return NULL;
}
+struct bpf_program *
+bpf_object__find_program_by_title(struct bpf_object *obj, const char *title)
+{
+ struct bpf_program *pos;
+
+ bpf_object__for_each_program(pos, obj) {
+ if (pos->section_name && !strcmp(pos->section_name, title))
+ return pos;
+ }
+ return NULL;
+}
+
static int
bpf_program__collect_reloc(struct bpf_program *prog, GElf_Shdr *shdr,
Elf_Data *data, struct bpf_object *obj)
diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
index 1f8fc2060460..a295fe2f822b 100644
--- a/tools/lib/bpf/libbpf.h
+++ b/tools/lib/bpf/libbpf.h
@@ -86,6 +86,9 @@ const char *bpf_object__name(struct bpf_object *obj);
unsigned int bpf_object__kversion(struct bpf_object *obj);
int bpf_object__btf_fd(const struct bpf_object *obj);
+struct bpf_program *
+bpf_object__find_program_by_title(struct bpf_object *obj, const char *title);
+
struct bpf_object *bpf_object__next(struct bpf_object *prev);
#define bpf_object__for_each_safe(pos, tmp) \
for ((pos) = bpf_object__next(NULL), \
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next 1/4] tools: libbpf: handle NULL program gracefully in bpf_program__nth_fd()
From: Jakub Kicinski @ 2018-07-26 21:32 UTC (permalink / raw)
To: alexei.starovoitov, daniel; +Cc: oss-drivers, netdev, Jakub Kicinski
In-Reply-To: <20180726213221.1295-1-jakub.kicinski@netronome.com>
bpf_map__fd() handles NULL map gracefully and returns -EINVAL.
bpf_program__fd() and bpf_program__nth_fd() crash in this case.
Make the behaviour more consistent by validating prog pointer
as well.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
---
tools/lib/bpf/libbpf.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 955f8eafbf41..afa9860db755 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -1991,6 +1991,9 @@ int bpf_program__nth_fd(struct bpf_program *prog, int n)
{
int fd;
+ if (!prog)
+ return -EINVAL;
+
if (n >= prog->instances.nr || n < 0) {
pr_warning("Can't get the %dth fd from program %s: only %d instances\n",
n, prog->section_name, prog->instances.nr);
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next 0/4] samples: bpf: convert two more samples to libbpf
From: Jakub Kicinski @ 2018-07-26 21:32 UTC (permalink / raw)
To: alexei.starovoitov, daniel; +Cc: oss-drivers, netdev, Jakub Kicinski
Hi!
This set converts xdpsock_user.c and xdp_fwd_user.c to use libbpf instead
of bpf_load.o. First two patches are minor improvements to libbpf to make
the conversion (and use of libbpf in general) nicer.
Jakub Kicinski (4):
tools: libbpf: handle NULL program gracefully in bpf_program__nth_fd()
tools: libbpf: add bpf_object__find_program_by_title()
samples: bpf: convert xdp_fwd_user.c to libbpf
samples: bpf: convert xdpsock_user.c to libbpf
samples/bpf/Makefile | 4 ++--
samples/bpf/xdp_fwd_user.c | 34 +++++++++++++++++++++++-----------
samples/bpf/xdpsock_user.c | 38 +++++++++++++++++++++++++++++---------
tools/lib/bpf/libbpf.c | 15 +++++++++++++++
tools/lib/bpf/libbpf.h | 3 +++
5 files changed, 72 insertions(+), 22 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH net-next] netdevsim: make debug dirs' dentries static
From: Jakub Kicinski @ 2018-07-26 21:25 UTC (permalink / raw)
To: davem; +Cc: oss-drivers, netdev, Jakub Kicinski
The root directories of netdevsim should only be used by the core
to create per-device subdirectories, so limit their visibility to
the core file.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
---
drivers/net/netdevsim/netdev.c | 6 +++---
drivers/net/netdevsim/netdevsim.h | 3 ---
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/netdevsim/netdev.c b/drivers/net/netdevsim/netdev.c
index 2d244551298b..8d8e2b3f263e 100644
--- a/drivers/net/netdevsim/netdev.c
+++ b/drivers/net/netdevsim/netdev.c
@@ -41,6 +41,9 @@ struct nsim_vf_config {
static u32 nsim_dev_id;
+static struct dentry *nsim_ddir;
+static struct dentry *nsim_sdev_ddir;
+
static int nsim_num_vf(struct device *dev)
{
struct netdevsim *ns = to_nsim(dev);
@@ -566,9 +569,6 @@ static struct rtnl_link_ops nsim_link_ops __read_mostly = {
.dellink = nsim_dellink,
};
-struct dentry *nsim_ddir;
-struct dentry *nsim_sdev_ddir;
-
static int __init nsim_module_init(void)
{
int err;
diff --git a/drivers/net/netdevsim/netdevsim.h b/drivers/net/netdevsim/netdevsim.h
index 02be199eb005..384c254fafc5 100644
--- a/drivers/net/netdevsim/netdevsim.h
+++ b/drivers/net/netdevsim/netdevsim.h
@@ -103,9 +103,6 @@ struct netdevsim {
struct nsim_ipsec ipsec;
};
-extern struct dentry *nsim_ddir;
-extern struct dentry *nsim_sdev_ddir;
-
#ifdef CONFIG_BPF_SYSCALL
int nsim_bpf_init(struct netdevsim *ns);
void nsim_bpf_uninit(struct netdevsim *ns);
--
2.17.1
^ permalink raw reply related
* Re: [net-next 1/6] ixgbe: Do not allow LRO or MTU change with XDP
From: Jakub Kicinski @ 2018-07-26 21:21 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Tony Nguyen, netdev, nhorman, sassmann, jogreene
In-Reply-To: <20180726174050.8923-2-jeffrey.t.kirsher@intel.com>
On Thu, 26 Jul 2018 10:40:45 -0700, Jeff Kirsher wrote:
> From: Tony Nguyen <anthony.l.nguyen@intel.com>
>
> XDP does not support jumbo frames or LRO. These checks are being made
> outside the driver when an XDP program is loaded, however, there is
> nothing preventing these from changing after an XDP program is loaded.
> Add the checks so that while an XDP program is loaded, do not allow MTU
> to be changed or LRO to be enabled.
>
> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
> Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index 5a6600f7b382..c42256e91997 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -6469,6 +6469,11 @@ static int ixgbe_change_mtu(struct net_device *netdev, int new_mtu)
> {
> struct ixgbe_adapter *adapter = netdev_priv(netdev);
>
> + if (adapter->xdp_prog) {
> + e_warn(probe, "MTU cannot be changed while XDP program is loaded\n");
> + return -EPERM;
EPERM looks wrong, EINVAL is common. Also most drivers will just check
the bounds like you do in ixgbe_xdp_setup(), allowing the change if new
MTU still fits constraints.
FWIW are the IXGBE_FLAG_SRIOV_ENABLED and IXGBE_FLAG_DCB_ENABLED flag
changes also covered while xdp is enabled? Quick grep doesn't reveal
them being checked against xdp_prog other than in ixgbe_xdp_setup().
> + }
> +
> /*
> * For 82599EB we cannot allow legacy VFs to enable their receive
> * paths when MTU greater than 1500 is configured. So display a
> @@ -9407,6 +9412,11 @@ static netdev_features_t ixgbe_fix_features(struct net_device *netdev,
> if (!(adapter->flags2 & IXGBE_FLAG2_RSC_CAPABLE))
> features &= ~NETIF_F_LRO;
>
> + if (adapter->xdp_prog && (features & NETIF_F_LRO)) {
> + e_dev_err("LRO is not supported with XDP\n");
> + features &= ~NETIF_F_LRO;
> + }
> +
> return features;
> }
>
^ permalink raw reply
* Re: [net-next 0/6][pull request] 10GbE Intel Wired LAN Driver Updates 2018-07-26
From: David Miller @ 2018-07-26 21:16 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <20180726174050.8923-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 26 Jul 2018 10:40:44 -0700
> This series contains updates to ixgbe and igb.
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [patch net-next] net: sched: unmark chain as explicitly created on delete
From: David Miller @ 2018-07-26 21:13 UTC (permalink / raw)
To: jiri; +Cc: netdev, jhs, xiyou.wangcong, mlxsw
In-Reply-To: <20180726162758.14306-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Thu, 26 Jul 2018 18:27:58 +0200
> From: Jiri Pirko <jiri@mellanox.com>
>
> Once user manually deletes the chain using "chain del", the chain cannot
> be marked as explicitly created anymore.
>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
> Fixes: 32a4f5ecd738 ("net: sched: introduce chain object to uapi")
Applied.
^ permalink raw reply
* Re: [PATCH net-next] l2tp: remove ->recv_payload_hook
From: David Miller @ 2018-07-26 21:07 UTC (permalink / raw)
To: g.nault; +Cc: netdev, jchapman
In-Reply-To: <6a20d71b1acf5a81fd80e06120cb40a06fed1c71.1532523126.git.g.nault@alphalink.fr>
From: Guillaume Nault <g.nault@alphalink.fr>
Date: Wed, 25 Jul 2018 14:53:33 +0200
> The tunnel reception hook is only used by l2tp_ppp for skipping PPP
> framing bytes. This is a session specific operation, but once a PPP
> session sets ->recv_payload_hook on its tunnel, all frames received by
> the tunnel will enter pppol2tp_recv_payload_hook(), including those
> targeted at Ethernet sessions (an L2TPv3 tunnel can multiplex PPP and
> Ethernet sessions).
>
> So this mechanism is wrong, and uselessly complex. Let's just move this
> functionality to the pppol2tp rx handler and drop ->recv_payload_hook.
>
> Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Applied, thanks Guillaume.
^ permalink raw reply
* Re: [PATCH net-next] net/tls: Removed redundant checks for non-NULL
From: David Miller @ 2018-07-26 21:02 UTC (permalink / raw)
To: vakul.garg; +Cc: netdev, borisp, aviadye, davejwatson
In-Reply-To: <20180724112427.16574-1-vakul.garg@nxp.com>
From: Vakul Garg <vakul.garg@nxp.com>
Date: Tue, 24 Jul 2018 16:54:27 +0530
> Removed checks against non-NULL before calling kfree_skb() and
> crypto_free_aead(). These functions are safe to be called with NULL
> as an argument.
>
> Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
Applied.
^ permalink raw reply
* Re: [PATCH net v2] net: rollback orig value on failure of dev_qdisc_change_tx_queue_len
From: David Miller @ 2018-07-26 21:01 UTC (permalink / raw)
To: tariqt; +Cc: netdev, eranbe, xiyou.wangcong
In-Reply-To: <1532430740-11443-1-git-send-email-tariqt@mellanox.com>
From: Tariq Toukan <tariqt@mellanox.com>
Date: Tue, 24 Jul 2018 14:12:20 +0300
> Fix dev_change_tx_queue_len so it rolls back original value
> upon a failure in dev_qdisc_change_tx_queue_len.
> This is already done for notifirers' failures, share the code.
>
> In case of failure in dev_qdisc_change_tx_queue_len, some tx queues
> would still be of the new length, while they should be reverted.
> Currently, the revert is not done, and is marked with a TODO label
> in dev_qdisc_change_tx_queue_len, and should find some nice solution
> to do it.
> Yet it is still better to not apply the newly requested value.
>
> Fixes: 48bfd55e7e41 ("net_sched: plug in qdisc ops change_tx_queue_len")
> Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
> Reviewed-by: Eran Ben Elisha <eranbe@mellanox.com>
> Reported-by: Ran Rozenstein <ranro@mellanox.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net-next] cbs: Add support for the graft function
From: David Miller @ 2018-07-26 20:58 UTC (permalink / raw)
To: vinicius.gomes
Cc: netdev, jesus.sanchez-palencia, henrik, richardcochran, jhs,
xiyou.wangcong, jiri, ilias.apalodimas
In-Reply-To: <20180724000800.14498-1-vinicius.gomes@intel.com>
From: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Date: Mon, 23 Jul 2018 17:08:00 -0700
> This will allow to install a child qdisc under cbs. The main use case
> is to install ETF (Earliest TxTime First) qdisc under cbs, so there's
> another level of control for time-sensitive traffic.
>
> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH] 9p: fix NULL pointer dereferences
From: Dominique Martinet @ 2018-07-26 22:15 UTC (permalink / raw)
To: Tomas Bortoli
Cc: Dmitry Vyukov, David Miller, v9fs-developer, netdev, LKML,
syzkaller
In-Reply-To: <baa7368f-e149-ef3d-cf10-4fcd16dce0e6@gmail.com>
Tomas Bortoli wrote on Thu, Jul 26, 2018:
> > If we want to preserve the current behaviour for trans=fd (and I don't
> > see why not) we just have to patch all the transports that use the
> > device, that is all .create functions but p9_fd_create()
> >
> > Basically exactly what you did, just for a few more functions - I
> > apparently was a little bit too optimistic thinking we could share
> > this check.
>
> Does v9fs_mount() knows the transport ahead? Because in that case it'd
> be possible to check if addr!=NULL && trans!=fd then return error
>
> Otherwise, patching all the .create, ok.
9p option parsing is all over the place, split in fs/9p/v9fs,
net/9p/client and net/9p/trans_*... Which is actually somewhat of a
problem because that means we can't warn on unused option as each parser
does not know the full subset of options used, so if someone makes a
typo they're on their own to figure it out :/
If you want to factor it in, v9fs_mount does not know which transport is
used, but p9_client_create does know - although the functions/structs
are all static so you need to check clnt->trans_mod->name with strcmp
and I'm honestly not sure that's better than checking in each function..
But, as usual I'm happy as long as it works, so pick your poison :)
--
Dominique Martinet
^ permalink raw reply
* Re: [PATCH net-next] rhashtable: detect when object movement between tables might have invalidated a lookup
From: David Miller @ 2018-07-26 20:55 UTC (permalink / raw)
To: neilb; +Cc: herbert, tgraf, netdev, linux-kernel, eric.dumazet
In-Reply-To: <876016r9z5.fsf@notabene.neil.brown.name>
From: NeilBrown <neilb@suse.com>
Date: Mon, 23 Jul 2018 11:56:14 +1000
> Some users of rhashtables might need to move an object from one table
> to another - this appears to be the reason for the incomplete usage
> of NULLS markers.
>
> To support these, we store a unique NULLS_MARKER at the end of
> each chain, and when a search fails to find a match, we check
> if the NULLS marker found was the expected one. If not,
> the search is repeated.
...
> This is a simplified version of a previous patch.
> It provides NULLS_MARKER support only for the specific use case
> which is currently thought be valuable to in-tree users
> of rhashtables.
Neil, this doesn't even compile:
In file included from lib/rhashtable.c:28:
lib/rhashtable.c: In function ‘rht_bucket_nested’:
./include/linux/rhashtable.h:79:2: error: initializer element is not computable at load time
((void *)NULLS_MARKER(((unsigned long) (ptr)) >> 1))
^
lib/rhashtable.c:1178:43: note: in expansion of macro ‘RHT_NULLS_MARKER’
static struct rhash_head __rcu *rhnull = RHT_NULLS_MARKER(&rhnull);
^~~~~~~~~~~~~~~~
make[1]: *** [scripts/Makefile.build:318: lib/rhashtable.o] Error 1
make: *** [Makefile:1653: lib/rhashtable.o] Error 2
I imagine you have a mix of other changes or whatever in your tree, so I'll
give you the benefit of the doubt.
But this is the second time this has happened with your rhashtable changes,
so...
^ permalink raw reply
* Re: [PATCH net-next] rhashtable: detect when object movement between tables might have invalidated a lookup
From: NeilBrown @ 2018-07-26 22:04 UTC (permalink / raw)
To: David Miller; +Cc: herbert, tgraf, netdev, linux-kernel, eric.dumazet
In-Reply-To: <20180726.135512.137481791294209800.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 6105 bytes --]
On Thu, Jul 26 2018, David Miller wrote:
> From: NeilBrown <neilb@suse.com>
> Date: Mon, 23 Jul 2018 11:56:14 +1000
>
>> Some users of rhashtables might need to move an object from one table
>> to another - this appears to be the reason for the incomplete usage
>> of NULLS markers.
>>
>> To support these, we store a unique NULLS_MARKER at the end of
>> each chain, and when a search fails to find a match, we check
>> if the NULLS marker found was the expected one. If not,
>> the search is repeated.
> ...
>> This is a simplified version of a previous patch.
>> It provides NULLS_MARKER support only for the specific use case
>> which is currently thought be valuable to in-tree users
>> of rhashtables.
>
> Neil, this doesn't even compile:
>
> In file included from lib/rhashtable.c:28:
> lib/rhashtable.c: In function ‘rht_bucket_nested’:
> ./include/linux/rhashtable.h:79:2: error: initializer element is not computable at load time
> ((void *)NULLS_MARKER(((unsigned long) (ptr)) >> 1))
> ^
> lib/rhashtable.c:1178:43: note: in expansion of macro ‘RHT_NULLS_MARKER’
> static struct rhash_head __rcu *rhnull = RHT_NULLS_MARKER(&rhnull);
> ^~~~~~~~~~~~~~~~
> make[1]: *** [scripts/Makefile.build:318: lib/rhashtable.o] Error 1
> make: *** [Makefile:1653: lib/rhashtable.o] Error 2
>
> I imagine you have a mix of other changes or whatever in your tree, so I'll
> give you the benefit of the doubt.
>
> But this is the second time this has happened with your rhashtable changes,
> so...
Your displeasure is understandable.
I had fixed this, but hadn't refreshed the patch - though I had updated
the patch description to explain the change I had to make - second
sentence of:
The unique NULLS_MARKER is derived from the address of the
head of the chain. As this cannot be derived at load-time the
static rhnull in rht_bucket_nexted() need to be initialised
at run time.
This is what I meant to send - it does compile.
Thanks,
NeilBrown
From: NeilBrown <neilb@suse.com>
Date: Mon, 25 Jun 2018 08:09:16 +1000
Subject: [PATCH] rhashtable: detect when object movement between tables might
have invalidated a lookup
Some users of rhashtables might need to move an object from one table
to another - this appears to be the reason for the incomplete usage
of NULLS markers.
To support these, we store a unique NULLS_MARKER at the end of
each chain, and when a search fails to find a match, we check
if the NULLS marker found was the expected one. If not,
the search is repeated.
The unique NULLS_MARKER is derived from the address of the
head of the chain. As this cannot be derived at load-time the
static rhnull in rht_bucket_nexted() need to be initialised
at run time.
Any caller of a lookup function must be prepared for the possibility
that the object returned is in a different table - it might have been
there for some time.
Note that this does NOT provide support for other uses for
NULLS_MARKERs such as allocating with SLAB_TYPESAFE_BY_RCU or changing
the key of an object and re-inserting it in the table.
These could only be done safely if new objects were inserted
at the *start* of a hash chain, and that is not currently the case.
Signed-off-by: NeilBrown <neilb@suse.com>
---
include/linux/rhashtable.h | 25 +++++++++++++++++--------
lib/rhashtable.c | 8 +++++---
2 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/include/linux/rhashtable.h b/include/linux/rhashtable.h
index eb7111039247..8cc240f14834 100644
--- a/include/linux/rhashtable.h
+++ b/include/linux/rhashtable.h
@@ -75,8 +75,10 @@ struct bucket_table {
struct rhash_head __rcu *buckets[] ____cacheline_aligned_in_smp;
};
+#define RHT_NULLS_MARKER(ptr) \
+ ((void *)NULLS_MARKER(((unsigned long) (ptr)) >> 1))
#define INIT_RHT_NULLS_HEAD(ptr) \
- ((ptr) = (typeof(ptr)) NULLS_MARKER(0))
+ ((ptr) = RHT_NULLS_MARKER(&(ptr)))
static inline bool rht_is_a_nulls(const struct rhash_head *ptr)
{
@@ -471,6 +473,7 @@ static inline struct rhash_head *__rhashtable_lookup(
.ht = ht,
.key = key,
};
+ struct rhash_head __rcu * const *head;
struct bucket_table *tbl;
struct rhash_head *he;
unsigned int hash;
@@ -478,13 +481,19 @@ static inline struct rhash_head *__rhashtable_lookup(
tbl = rht_dereference_rcu(ht->tbl, ht);
restart:
hash = rht_key_hashfn(ht, tbl, key, params);
- rht_for_each_rcu(he, tbl, hash) {
- if (params.obj_cmpfn ?
- params.obj_cmpfn(&arg, rht_obj(ht, he)) :
- rhashtable_compare(&arg, rht_obj(ht, he)))
- continue;
- return he;
- }
+ head = rht_bucket(tbl, hash);
+ do {
+ rht_for_each_rcu_continue(he, *head, tbl, hash) {
+ if (params.obj_cmpfn ?
+ params.obj_cmpfn(&arg, rht_obj(ht, he)) :
+ rhashtable_compare(&arg, rht_obj(ht, he)))
+ continue;
+ return he;
+ }
+ /* An object might have been moved to a different hash chain,
+ * while we walk along it - better check and retry.
+ */
+ } while (he != RHT_NULLS_MARKER(head));
/* Ensure we see any new tables. */
smp_rmb();
diff --git a/lib/rhashtable.c b/lib/rhashtable.c
index ae4223e0f5bc..0b1baede369c 100644
--- a/lib/rhashtable.c
+++ b/lib/rhashtable.c
@@ -1175,8 +1175,7 @@ struct rhash_head __rcu **rht_bucket_nested(const struct bucket_table *tbl,
unsigned int hash)
{
const unsigned int shift = PAGE_SHIFT - ilog2(sizeof(void *));
- static struct rhash_head __rcu *rhnull =
- (struct rhash_head __rcu *)NULLS_MARKER(0);
+ static struct rhash_head __rcu *rhnull;
unsigned int index = hash & ((1 << tbl->nest) - 1);
unsigned int size = tbl->size >> tbl->nest;
unsigned int subhash = hash;
@@ -1194,8 +1193,11 @@ struct rhash_head __rcu **rht_bucket_nested(const struct bucket_table *tbl,
subhash >>= shift;
}
- if (!ntbl)
+ if (!ntbl) {
+ if (!rhnull)
+ INIT_RHT_NULLS_HEAD(rhnull);
return &rhnull;
+ }
return &ntbl[subhash].bucket;
--
2.14.0.rc0.dirty
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply related
* [PATCH net] net: ena: Fix use of uninitialized DMA address bits field
From: Gal Pressman @ 2018-07-26 20:40 UTC (permalink / raw)
To: netdev, Netanel Belgazal; +Cc: Gal Pressman
UBSAN triggers the following undefined behaviour warnings:
[...]
[ 13.236124] UBSAN: Undefined behaviour in drivers/net/ethernet/amazon/ena/ena_eth_com.c:468:22
[ 13.240043] shift exponent 64 is too large for 64-bit type 'long long unsigned int'
[...]
[ 13.744769] UBSAN: Undefined behaviour in drivers/net/ethernet/amazon/ena/ena_eth_com.c:373:4
[ 13.748694] shift exponent 64 is too large for 64-bit type 'long long unsigned int'
[...]
When splitting the address to high and low, GENMASK_ULL is used to generate
a bitmask with dma_addr_bits field from io_sq (in ena_com_prepare_tx and
ena_com_add_single_rx_desc).
The problem is that dma_addr_bits is not initialized with a proper value
(besides being cleared in ena_com_create_io_queue).
Assign dma_addr_bits the correct value that is stored in ena_dev when
initializing the SQ.
Fixes: 1738cd3ed342 ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)")
Signed-off-by: Gal Pressman <pressmangal@gmail.com>
---
drivers/net/ethernet/amazon/ena/ena_com.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/amazon/ena/ena_com.c b/drivers/net/ethernet/amazon/ena/ena_com.c
index 1b9d3130af4d..17f12c18d225 100644
--- a/drivers/net/ethernet/amazon/ena/ena_com.c
+++ b/drivers/net/ethernet/amazon/ena/ena_com.c
@@ -333,6 +333,7 @@ static int ena_com_init_io_sq(struct ena_com_dev *ena_dev,
memset(&io_sq->desc_addr, 0x0, sizeof(io_sq->desc_addr));
+ io_sq->dma_addr_bits = ena_dev->dma_addr_bits;
io_sq->desc_entry_size =
(io_sq->direction == ENA_COM_IO_QUEUE_DIRECTION_TX) ?
sizeof(struct ena_eth_io_tx_desc) :
--
2.14.4
^ permalink raw reply related
* Re: [PATCH] net: sched: cls_api: fix dead code in switch
From: Gustavo A. R. Silva @ 2018-07-26 21:32 UTC (permalink / raw)
To: David Miller; +Cc: jiri, jhs, xiyou.wangcong, netdev, linux-kernel
In-Reply-To: <20180726.141022.1379401977396818228.davem@davemloft.net>
On 07/26/2018 04:10 PM, David Miller wrote:
> From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
> Date: Wed, 25 Jul 2018 09:07:24 -0500
>
>> Code at line 1850 is unreachable. Fix this by removing the break
>> statement above it, so the code for case RTM_GETCHAIN can be
>> properly executed.
>>
>> Addresses-Coverity-ID: 1472050 ("Structurally dead code")
>> Fixes: 32a4f5ecd738 ("net: sched: introduce chain object to uapi")
>> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
>
> Applied, thanks.
>
> Please use "[PATCH net-next] ..." in your subject lines to indirect
> the tree that this change is relevant for and targetted to.
>
Got it. Will do next time.
Thanks
--
Gustavo
^ permalink raw reply
* Re: [patch net-next RFC] net: sched: don't dump chains only held by actions
From: Jakub Kicinski @ 2018-07-26 19:59 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, jhs, xiyou.wangcong, mlxsw
In-Reply-To: <20180726163101.19718-1-jiri@resnulli.us>
On Thu, 26 Jul 2018 18:31:01 +0200, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@mellanox.com>
>
> In case a chain is empty and not explicitly created by a user,
> such chain should not exist. The only exception is if there is
> an action "goto chain" pointing to it. In that case, don't show the
> chain in the dump. Track the chain references held by actions and
> use them to find out if a chain should or should not be shown
> in chain dump.
>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
I don't have any better ideas :)
One question below.
> diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
> index 75cce2819de9..76035cd6e3bf 100644
> --- a/net/sched/cls_api.c
> +++ b/net/sched/cls_api.c
> @@ -262,6 +262,25 @@ static void tcf_chain_hold(struct tcf_chain *chain)
> ++chain->refcnt;
> }
>
> +static void tcf_chain_hold_by_act(struct tcf_chain *chain)
> +{
> + ++chain->action_refcnt;
> +}
> +
> +static void tcf_chain_release_by_act(struct tcf_chain *chain)
> +{
> + --chain->action_refcnt;
> +}
> +
> +static bool tcf_chain_is_zombie(struct tcf_chain *chain)
> +{
> + /* In case all the references are action references, this
> + * chain is a zombie and should not be listed in the chain
> + * dump list.
> + */
> + return chain->refcnt == chain->action_refcnt;
> +}
> +
> static struct tcf_chain *tcf_chain_lookup(struct tcf_block *block,
> u32 chain_index)
> {
> @@ -298,6 +317,15 @@ struct tcf_chain *tcf_chain_get(struct tcf_block *block, u32 chain_index,
> }
> EXPORT_SYMBOL(tcf_chain_get);
>
> +struct tcf_chain *tcf_chain_get_by_act(struct tcf_block *block, u32 chain_index)
> +{
> + struct tcf_chain *chain = tcf_chain_get(block, chain_index, true);
> +
> + tcf_chain_hold_by_act(chain);
> + return chain;
> +}
> +EXPORT_SYMBOL(tcf_chain_get_by_act);
> +
> static void tc_chain_tmplt_del(struct tcf_chain *chain);
>
> void tcf_chain_put(struct tcf_chain *chain)
> @@ -310,6 +338,13 @@ void tcf_chain_put(struct tcf_chain *chain)
> }
> EXPORT_SYMBOL(tcf_chain_put);
>
> +void tcf_chain_put_by_act(struct tcf_chain *chain)
> +{
> + tcf_chain_release_by_act(chain);
> + tcf_chain_put(chain);
> +}
> +EXPORT_SYMBOL(tcf_chain_put_by_act);
> +
> static void tcf_chain_put_explicitly_created(struct tcf_chain *chain)
> {
> if (chain->explicitly_created)
> @@ -1803,17 +1838,26 @@ static int tc_ctl_chain(struct sk_buff *skb, struct nlmsghdr *n,
> chain = tcf_chain_lookup(block, chain_index);
> if (n->nlmsg_type == RTM_NEWCHAIN) {
> if (chain) {
> - NL_SET_ERR_MSG(extack, "Filter chain already exists");
> - return -EEXIST;
> - }
> - if (!(n->nlmsg_flags & NLM_F_CREATE)) {
> - NL_SET_ERR_MSG(extack, "Need both RTM_NEWCHAIN and NLM_F_CREATE to create a new chain");
> - return -ENOENT;
> - }
> - chain = tcf_chain_create(block, chain_index);
> - if (!chain) {
> - NL_SET_ERR_MSG(extack, "Failed to create filter chain");
> - return -ENOMEM;
> + if (tcf_chain_is_zombie(chain)) {
> + /* The chain exists only because there is
> + * some action referencing it, meaning it
> + * is a zombie.
> + */
> + tcf_chain_hold(chain);
I'm not 100% sure why this is needed? In my tree below I see:
switch (n->nlmsg_type) {
case RTM_NEWCHAIN:
err = tc_chain_tmplt_add(chain, net, tca, extack);
if (err)
goto errout;
/* In case the chain was successfully added, take a reference
* to the chain. This ensures that an empty chain
* does not disappear at the end of this function.
*/
tcf_chain_hold(chain);
chain->explicitly_created = true;
so one reference will be taken.. do we need two?
> + } else {
> + NL_SET_ERR_MSG(extack, "Filter chain already exists");
> + return -EEXIST;
> + }
> + } else {
> + if (!(n->nlmsg_flags & NLM_F_CREATE)) {
> + NL_SET_ERR_MSG(extack, "Need both RTM_NEWCHAIN and NLM_F_CREATE to create a new chain");
> + return -ENOENT;
> + }
> + chain = tcf_chain_create(block, chain_index);
> + if (!chain) {
> + NL_SET_ERR_MSG(extack, "Failed to create filter chain");
> + return -ENOMEM;
> + }
> }
> } else {
> if (!chain) {
> @@ -1944,6 +1988,8 @@ static int tc_dump_chain(struct sk_buff *skb, struct netlink_callback *cb)
> index++;
> continue;
> }
> + if (tcf_chain_is_zombie(chain))
> + continue;
> err = tc_chain_fill_node(chain, net, skb, block,
> NETLINK_CB(cb->skb).portid,
> cb->nlh->nlmsg_seq, NLM_F_MULTI,
^ permalink raw reply
* Re: [PATCH] net: sched: cls_api: fix dead code in switch
From: David Miller @ 2018-07-26 21:10 UTC (permalink / raw)
To: gustavo; +Cc: jiri, jhs, xiyou.wangcong, netdev, linux-kernel
In-Reply-To: <20180725140724.GA23053@embeddedor.com>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Wed, 25 Jul 2018 09:07:24 -0500
> Code at line 1850 is unreachable. Fix this by removing the break
> statement above it, so the code for case RTM_GETCHAIN can be
> properly executed.
>
> Addresses-Coverity-ID: 1472050 ("Structurally dead code")
> Fixes: 32a4f5ecd738 ("net: sched: introduce chain object to uapi")
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied, thanks.
Please use "[PATCH net-next] ..." in your subject lines to indirect
the tree that this change is relevant for and targetted to.
Thank you.
^ permalink raw reply
* Re: [PATCH 7/7] net: phy: Add pm support for scan ctrl register to bcm mdio mux
From: Arun Parameswaran @ 2018-07-26 19:51 UTC (permalink / raw)
To: Andrew Lunn
Cc: David S. Miller, Florian Fainelli, Rob Herring, Mark Rutland,
Ray Jui, Scott Branden, Catalin Marinas, Will Deacon, netdev,
devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list
In-Reply-To: <20180726193634.GM10686@lunn.ch>
Hi Andrew,
On 18-07-26 12:36 PM, Andrew Lunn wrote:
> On Thu, Jul 26, 2018 at 12:33:05PM -0700, Arun Parameswaran wrote:
>>
>>
>> On 18-07-26 12:20 PM, Andrew Lunn wrote:
>>> On Thu, Jul 26, 2018 at 11:36:24AM -0700, Arun Parameswaran wrote:
>>>> Add support for saving and restoring the 'scan control' register
>>>> in the Broadcom iProc mdio mux driver.
>>>
>>> Hi Arun
>>>
>>> I don't see anything setting this register. So why is it necessary to
>>> save it over suspend/resume?
>>>
>>> Andrew
>>>
>> Hi Andrew
>> In the Omega SoC (only), this register was defaulted incorrectly (to use
>> a test mode) by the hardware. So we added the setup of the register to
>> the early bootloader (ATF).
>>
>> We still need to restore this register while resuming from sleep.
>
> Hi Arun
>
> It is better to not rely on the bootloader and have the driver do it.
> That makes it easier for people to swap to alternative bootloaders.
>
> Andrew
>
I will make the change to set the register in the driver.
Thanks
Arun
^ permalink raw reply
* Re: [PATCH net-next] tipc: add missing dev_put() on error in tipc_enable_l2_media
From: David Miller @ 2018-07-26 21:05 UTC (permalink / raw)
To: yuehaibing; +Cc: jon.maloy, ying.xue, linux-kernel, netdev, tipc-discussion
In-Reply-To: <20180725100049.20244-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Wed, 25 Jul 2018 18:00:49 +0800
> when tipc_own_id failed to obtain node identity,dev_put should
> be call before return -EINVAL.
>
> Fixes: 682cd3cf946b ("tipc: confgiure and apply UDP bearer MTU on running links")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied to net-next, thank you.
^ permalink raw reply
* Re: [PATCH] RDS: RDMA: Fix the NULL-ptr deref in rds_ib_get_mr
From: David Miller @ 2018-07-26 21:04 UTC (permalink / raw)
To: avinash.repaka
Cc: santosh.shilimkar, netdev, linux-rdma, rds-devel, linux-kernel
In-Reply-To: <1532489518-27042-1-git-send-email-avinash.repaka@oracle.com>
From: Avinash Repaka <avinash.repaka@oracle.com>
Date: Tue, 24 Jul 2018 20:31:58 -0700
> Registration of a memory region(MR) through FRMR/fastreg(unlike FMR)
> needs a connection/qp. With a proxy qp, this dependency on connection
> will be removed, but that needs more infrastructure patches, which is a
> work in progress.
>
> As an intermediate fix, the get_mr returns EOPNOTSUPP when connection
> details are not populated. The MR registration through sendmsg() will
> continue to work even with fast registration, since connection in this
> case is formed upfront.
>
> This patch fixes the following crash:
...
> Reported-by: syzbot+b51c77ef956678a65834@syzkaller.appspotmail.com
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
> Signed-off-by: Avinash Repaka <avinash.repaka@oracle.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] net: sort Kconfig menu items alphabetically
From: David Miller @ 2018-07-26 20:39 UTC (permalink / raw)
To: jdmason
Cc: helgaas, f.fainelli, rasesh.mody, sudarsana.kalluru,
Dept-GELinuxNICDev, netdev, linux-kernel
In-Reply-To: <20180724154340.GA5871@kudzu.us>
From: Jon Mason <jdmason@kudzu.us>
Date: Tue, 24 Jul 2018 11:43:41 -0400
> On Mon, Jul 23, 2018 at 04:01:14PM -0500, Bjorn Helgaas wrote:
>> From: Bjorn Helgaas <bhelgaas@google.com>
>>
>> 6c541b4595a2 ("net: ethernet: Sort Kconfig sourcing alphabetically")
>> sorted Kconfig sourcing based on directory names, but in a couple cases,
>> the menu item text is quite different from the directory name and is not
>> sorted correctly:
>>
>> drivers/net/ethernet/neterion/Kconfig => "Exar devices"
>
> Stupid question, does it make more sense to clarify the names in the
> Kconfig to more naturally follow what people are expecting? In the
> case of Neterion, it was standalone for several years, then aquired by
> Exar and shutdown in 11 months without ever making any Exar branded
> adatpers. Users, if they still exist, would probably think of it as
> Neterion and not Exar (as there have been no follow-on adapters and I
> don't believe any plans to ever do so).
>
> So, this might be better as a rename of the Kconfig to something like
> "Neterion (Exar) devices". Of course, there is a fair amount of Exar
> names in the Kconfig. If you agree, I can do a clean-up of this to
> match the expectations.
>
> Thoughts?
I think this is a better way to handle this.
That way, a developer can read the Kconfig file and see if the entries
are sorted properly without having to check the text of every
sub-directory entry.
^ permalink raw reply
* Re: [PATCH 5/7] net: phy: Add support to configure clock in Broadcom iProc mdio mux
From: Arun Parameswaran @ 2018-07-26 19:20 UTC (permalink / raw)
To: Andrew Lunn
Cc: David S. Miller, Florian Fainelli, Rob Herring, Mark Rutland,
Ray Jui, Scott Branden, Catalin Marinas, Will Deacon, netdev,
devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list
In-Reply-To: <20180726191340.GH10686@lunn.ch>
On 18-07-26 12:13 PM, Andrew Lunn wrote:
>> @@ -175,6 +198,12 @@ static int mdio_mux_iproc_probe(struct platform_device *pdev)
>> return PTR_ERR(md->base);
>> }
>>
>> + md->core_clk = devm_clk_get(&pdev->dev, NULL);
>> + if (IS_ERR(md->core_clk)) {
>> + dev_info(&pdev->dev, "core_clk not specified\n");
>> + md->core_clk = NULL;
>> + }
>> +
>
> In the binding, you say the clock is optional. This is a rather strong
> message for something which is optional. I think it would be better to
> not output anything.
>
> Andrew
>
Will remove the message.
Thanks
Arun
^ permalink raw reply
* Re: [PATCH 2/7] net: phy: Fix the register offsets in Broadcom iProc mdio mux driver
From: Arun Parameswaran @ 2018-07-26 19:16 UTC (permalink / raw)
To: Andrew Lunn
Cc: David S. Miller, Florian Fainelli, Rob Herring, Mark Rutland,
Ray Jui, Scott Branden, Catalin Marinas, Will Deacon, netdev,
devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list
In-Reply-To: <20180726190636.GG10686@lunn.ch>
On 18-07-26 12:06 PM, Andrew Lunn wrote:
> On Thu, Jul 26, 2018 at 11:36:19AM -0700, Arun Parameswaran wrote:
>> Modify the register offsets in the Broadcom iProc mdio mux to start
>> from the top of the register address space.
>>
>> Earlier the base address specified was from the middle of the block's
>> register space. The base address will now point to the start of the
>> mdio's address space. The offsets have been fixed to match this.
>
> Hi Arun
>
> Did you consider a change something like:
That looks good. I will make this change to the patch.
Thanks
Arun
>
> diff --git a/drivers/net/phy/mdio-mux-bcm-iproc.c b/drivers/net/phy/mdio-mux-bcm-iproc.c
> index 0831b7142df7..2d53e609498c 100644
> --- a/drivers/net/phy/mdio-mux-bcm-iproc.c
> +++ b/drivers/net/phy/mdio-mux-bcm-iproc.c
> @@ -169,6 +169,12 @@ static int mdio_mux_iproc_probe(struct platform_device *pdev)
> md->dev = &pdev->dev;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +
> + if (res->start & 0xfff != 0) {
> + dev_info(&pdev->dev, "Please upgrade your device tree blob.\n");
> + res->start &= ~0xfff;
> + }
> +
> md->base = devm_ioremap_resource(&pdev->dev, res);
> if (IS_ERR(md->base)) {
> dev_err(&pdev->dev, "failed to ioremap register\n");
>
>
> Andrew
>
^ permalink raw reply
* Re: [PATCH 0/7] Add clock config and pm support to bcm iProc mdio mux
From: Arun Parameswaran @ 2018-07-26 19:00 UTC (permalink / raw)
To: Andrew Lunn
Cc: David S. Miller, Florian Fainelli, Rob Herring, Mark Rutland,
Ray Jui, Scott Branden, Catalin Marinas, Will Deacon, netdev,
devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list
In-Reply-To: <20180726185246.GE10686@lunn.ch>
On 18-07-26 11:52 AM, Andrew Lunn wrote:
> On Thu, Jul 26, 2018 at 11:36:17AM -0700, Arun Parameswaran wrote:
>> Hi,
>> The patchset is based on David Miller's "net" repo.
>
> Hi Arun
>
> "net" is intended for bug fixes. This looks like new features, so
> should be against net-next". Please read the netdev FAQ.
>
> Andrew
>
Hi Andrew
The first three patches are 'fixes', and the subsequent patches
(which are new features) depend on the first 3 patches.
Since I had the 'fixes', and the dependency, I used the 'net'
repo.
Please advise if I should still use 'net-next' for all of them.
Thanks
Arun
^ 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