* Re: [PATCH net] inet: frag: enforce memory limits earlier
From: David Miller @ 2018-07-31 21:44 UTC (permalink / raw)
To: edumazet; +Cc: netdev, jannh, eric.dumazet, fw, posk, pabeni
In-Reply-To: <20180731030911.248637-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Mon, 30 Jul 2018 20:09:11 -0700
> We currently check current frags memory usage only when
> a new frag queue is created. This allows attackers to first
> consume the memory budget (default : 4 MB) creating thousands
> of frag queues, then sending tiny skbs to exceed high_thresh
> limit by 2 to 3 order of magnitude.
>
> Note that before commit 648700f76b03 ("inet: frags: use rhashtables
> for reassembly units"), work queue could be starved under DOS,
> getting no cpu cycles.
> After commit 648700f76b03, only the per frag queue timer can eventually
> remove an incomplete frag queue and its skbs.
>
> Fixes: b13d3cbfb8e8 ("inet: frag: move eviction of queues to work queue")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Jann Horn <jannh@google.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [pull request][net 0/4] Mellanox, mlx5 fixes 2018-07-31
From: David Miller @ 2018-07-31 21:36 UTC (permalink / raw)
To: saeedm; +Cc: netdev
In-Reply-To: <20180731202959.32729-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Tue, 31 Jul 2018 13:29:55 -0700
> The following series includes four mlx5 fixes.
>
> Please pull and let me know if there's any problem.
>
> For -stable v4.14
> net/mlx5e: E-Switch, Initialize eswitch only if eswitch manager
>
> For -stable v4.16
> net/mlx5e: Set port trust mode to PCP as default
>
> For -stable v4.17
> net/mlx5e: IPoIB, Set the netdevice sw mtu in ipoib enhanced flow
Pulled and queued up for -stable.
^ permalink raw reply
* Re: [PATCH v4 bpf-next 08/14] bpf: introduce the bpf_get_local_storage() helper function
From: Daniel Borkmann @ 2018-07-31 22:50 UTC (permalink / raw)
To: Roman Gushchin, netdev; +Cc: linux-kernel, kernel-team, Alexei Starovoitov
In-Reply-To: <20180727215243.3850-9-guro@fb.com>
On 07/27/2018 11:52 PM, Roman Gushchin wrote:
[...]
> @@ -2533,6 +2541,16 @@ static int check_helper_call(struct bpf_verifier_env *env, int func_id, int insn
> }
>
> regs = cur_regs(env);
> +
> + /* check that flags argument in get_local_storage(map, flags) is 0,
> + * this is required because get_local_storage() can't return an error.
> + */
> + if (func_id == BPF_FUNC_get_local_storage &&
> + !tnum_equals_const(regs[BPF_REG_2].var_off, 0)) {
> + verbose(env, "get_local_storage() doesn't support non-zero flags\n");
> + return -EINVAL;
> + }
Hmm, this check is actually not correct. You will still be able to pass non-zero
values in there. arg2_type from the helper is ARG_ANYTHING, so the register type
could for example be one of the pointer types and it will still pass the verifier.
The correct way to check would be to use register_is_null().
> +
> /* reset caller saved regs */
> for (i = 0; i < CALLER_SAVED_REGS; i++) {
> mark_reg_not_init(env, regs, caller_saved[i]);
^ permalink raw reply
* Re: [PATCH v2] bpf: verifier: MOV64 don't mark dst reg unbounded
From: Daniel Borkmann @ 2018-07-31 21:07 UTC (permalink / raw)
To: Arthur Fabre, Alexei Starovoitov, Y Song, Edward Cree, netdev
In-Reply-To: <20180731171722.6122-1-afabre@cloudflare.com>
On 07/31/2018 07:17 PM, Arthur Fabre wrote:
> When check_alu_op() handles a BPF_MOV64 between two registers,
> it calls check_reg_arg(DST_OP) on the dst register, marking it as unbounded.
> If the src and dst register are the same, this marks the src as
> unbounded, which can lead to unexpected errors for further checks that
> rely on bounds info. For example:
>
> BPF_MOV64_IMM(BPF_REG_2, 0),
> BPF_MOV64_REG(BPF_REG_2, BPF_REG_2),
> BPF_ALU64_REG(BPF_ADD, BPF_REG_1, BPF_REG_2),
> BPF_MOV64_IMM(BPF_REG_0, 0),
> BPF_EXIT_INSN(),
>
> results in:
>
> "math between ctx pointer and register with unbounded min value is not
> allowed"
>
> check_alu_op() now uses check_reg_arg(DST_OP_NO_MARK), and MOVs
> that need to mark the dst register (MOVIMM, MOV32) do so.
>
> Added a test case for MOV64 dst == src, and dst != src.
>
> Signed-off-by: Arthur Fabre <afabre@cloudflare.com>
Looks good, applied to bpf-next, thanks Arthur!
^ permalink raw reply
* Re: [PATCH v2] Add BPF_SYNCHRONIZE_MAPS bpf(2) command
From: Daniel Borkmann @ 2018-07-31 22:30 UTC (permalink / raw)
To: Joel Fernandes, Y Song
Cc: Joel Fernandes, Alexei Starovoitov, Daniel Colascione, LKML,
Tim Murray, Network Development, Lorenzo Colitti, Chenbo Feng,
Mathieu Desnoyers, Alexei Starovoitov
In-Reply-To: <20180731215651.GA141321@joelaf.mtv.corp.google.com>
On 07/31/2018 11:56 PM, Joel Fernandes wrote:
> On Mon, Jul 30, 2018 at 09:03:18PM -0700, Y Song wrote:
>> On Mon, Jul 30, 2018 at 7:06 PM, Joel Fernandes <joel@joelfernandes.org> wrote:
>>> On Mon, Jul 30, 2018 at 07:01:22PM -0700, Joel Fernandes wrote:
>>>> On Sun, Jul 29, 2018 at 06:51:18PM +0300, Alexei Starovoitov wrote:
>>>>> On Thu, Jul 26, 2018 at 7:51 PM, Daniel Colascione <dancol@google.com> wrote:
>>>>>> BPF_SYNCHRONIZE_MAPS waits for the release of any references to a BPF
>>>>>> map made by a BPF program that is running at the time the
>>>>>> BPF_SYNCHRONIZE_MAPS command is issued. The purpose of this command is
>>>>>> to provide a means for userspace to replace a BPF map with another,
>>>>>> newer version, then ensure that no component is still using the "old"
>>>>>> map before manipulating the "old" map in some way.
>>>>>>
>>>>>> Signed-off-by: Daniel Colascione <dancol@google.com>
>>>>>> ---
>>>>>> include/uapi/linux/bpf.h | 9 +++++++++
>>>>>> kernel/bpf/syscall.c | 13 +++++++++++++
>>>>>> 2 files changed, 22 insertions(+)
>>>>>>
>>>>>> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
>>>>>> index b7db3261c62d..5b27e9117d3e 100644
>>>>>> --- a/include/uapi/linux/bpf.h
>>>>>> +++ b/include/uapi/linux/bpf.h
>>>>>> @@ -75,6 +75,14 @@ struct bpf_lpm_trie_key {
>>>>>> __u8 data[0]; /* Arbitrary size */
>>>>>> };
>>>>>>
>>>>>> +/* BPF_SYNCHRONIZE_MAPS waits for the release of any references to a
>>>>>> + * BPF map made by a BPF program that is running at the time the
>>>>>> + * BPF_SYNCHRONIZE_MAPS command is issued. The purpose of this command
>>>>>
>>>>> that doesn't sound right to me.
>>>>> such command won't wait for the release of the references.
>>>>> in case of map-in-map the program does not hold
>>>>> the references to inner map (only to outer map).
>>>>
>>>> I didn't follow this completely.
>>>>
>>>> The userspace program is using the inner map per your description of the
>>>> algorithm for using map-in-map to solve the race conditions that this patch
>>>> is trying to address:
>>>>
>>>> If you don't mind, I copy-pasted it below from your netdev post:
>>>>
>>>> if you use map-in-map you don't need extra boolean map.
>>>> 0. bpf prog can do
>>>> inner_map = lookup(map_in_map, key=0);
>>>> lookup(inner_map, your_real_key);
>>>> 1. user space writes into map_in_map[0] <- FD of new map
>>>> 2. some cpus are using old inner map and some a new
>>>> 3. user space does sys_membarrier(CMD_GLOBAL) which will do synchronize_sched()
>>>> which in CONFIG_PREEMPT_NONE=y servers is the same as synchronize_rcu()
>>>> which will guarantee that progs finished.
>>>> 4. scan old inner map
>>>>
>>>> In step 2, as you mentioned there are CPUs using different inner maps. So
>>>> could you clarify how the synchronize_rcu mechanism will even work if you're
>>>> now saying "program does not hold references to the inner maps"?
>>
>> The program only held references to the outer maps, and the outer map
>> held references to the inner maps. The user space program can add/remove
>> the inner map for a particular outer map while the prog <-> outer-map
>> relationship is not changed.
>
> My definition of "reference" in this context is protection by rcu_read_lock.
>
> So I was concerned the above map-in-map access isn't protected as such when
> Alexei said "program doesn't have reference on inner map" in the above steps.
> Maybe I misunderstood what is the meaning of reference here.
>
> To make the map-in-map thing to work for Chenbo/Lorenzo's usecase, both the
> access of outer map at key=0 and the inner map have to protect by
> rcu_read_lock so that the membarrier call will work.
>
> So basically step 0 in the steps above should be rcu_read_lock protected to
> satisfy Chenbo/Lorenzo's usecase.
>
> I know today the entire program is run as preempt disabled (unless something
> changed) so this shouldn't be a problem, but in the future if the verifier is
> doing similar things at a finer grainer level, then the above has to be
> taken into consideration.
>
> Does that make sense or am I missing something?
All BPF programs are required to run under rcu_read_lock today, so that
assumption holds. Should this ever change in future, then this constraint
of course needs to be taken into consideration.
Thanks,
Daniel
^ permalink raw reply
* [net 4/4] net/mlx5e: IPoIB, Set the netdevice sw mtu in ipoib enhanced flow
From: Saeed Mahameed @ 2018-07-31 20:29 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Feras Daoud, Saeed Mahameed
In-Reply-To: <20180731202959.32729-1-saeedm@mellanox.com>
From: Feras Daoud <ferasda@mellanox.com>
After introduction of the cited commit, mlx5e_build_nic_params
receives the netdevice mtu in order to set the sw_mtu of mlx5e_params.
For enhanced IPoIB, the netdevice mtu is not set in this stage,
therefore, the initial sw_mtu equals zero. As a result, the hw_mtu
of the receive queue will be calculated incorrectly causing traffic
issues.
To fix this issue, query for port mtu before building the nic params.
Fixes: 472a1e44b349 ("net/mlx5e: Save MTU in channels params")
Signed-off-by: Feras Daoud <ferasda@mellanox.com>
Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/ipoib/ipoib.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/ipoib/ipoib.c b/drivers/net/ethernet/mellanox/mlx5/core/ipoib/ipoib.c
index af3bb2f7a504..b7c21eb21a21 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/ipoib/ipoib.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/ipoib/ipoib.c
@@ -76,6 +76,7 @@ void mlx5i_init(struct mlx5_core_dev *mdev,
void *ppriv)
{
struct mlx5e_priv *priv = mlx5i_epriv(netdev);
+ u16 max_mtu;
/* priv init */
priv->mdev = mdev;
@@ -84,6 +85,9 @@ void mlx5i_init(struct mlx5_core_dev *mdev,
priv->ppriv = ppriv;
mutex_init(&priv->state_lock);
+ mlx5_query_port_max_mtu(mdev, &max_mtu, 1);
+ netdev->mtu = max_mtu;
+
mlx5e_build_nic_params(mdev, &priv->channels.params,
profile->max_nch(mdev), netdev->mtu);
mlx5i_build_nic_params(mdev, &priv->channels.params);
--
2.17.0
^ permalink raw reply related
* [net 2/4] net/mlx5e: Set port trust mode to PCP as default
From: Saeed Mahameed @ 2018-07-31 20:29 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Or Gerlitz, Saeed Mahameed
In-Reply-To: <20180731202959.32729-1-saeedm@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
The hairpin offload code has dependency on the trust mode being PCP.
Hence we should set PCP as the default for handling cases where we are
disallowed to read the trust mode from the FW, or failed to initialize it.
Fixes: 106be53b6b0a ('net/mlx5e: Set per priority hairpin pairs')
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Reviewed-by: Parav Pandit <parav@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c b/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
index 86bc9ac99586..e33afa8d2417 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
@@ -1172,6 +1172,8 @@ static int mlx5e_trust_initialize(struct mlx5e_priv *priv)
struct mlx5_core_dev *mdev = priv->mdev;
int err;
+ priv->dcbx_dp.trust_state = MLX5_QPTS_TRUST_PCP;
+
if (!MLX5_DSCP_SUPPORTED(mdev))
return 0;
--
2.17.0
^ permalink raw reply related
* [net 3/4] net/mlx5e: Fix null pointer access when setting MTU of vport representor
From: Saeed Mahameed @ 2018-07-31 20:29 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Adi Nissim, Saeed Mahameed
In-Reply-To: <20180731202959.32729-1-saeedm@mellanox.com>
From: Adi Nissim <adin@mellanox.com>
MTU helper function is used by both conventional mlx5e
instances (PF/VF) and the eswitch representors. The representor
shouldn't change the nic vport context MTU, the VF is responsible for
that. Therefore set_mtu_cb has a null value when changing the
representor MTU.
Fixes: 250a42b6a764 ("net/mlx5e: Support configurable MTU for vport representors")
Signed-off-by: Adi Nissim <adin@mellanox.com>
Reviewed-by: Yevgeny Kliteynik <kliteyn@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index dae4156a710d..c592678ab5f1 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -3712,7 +3712,8 @@ int mlx5e_change_mtu(struct net_device *netdev, int new_mtu,
if (!reset) {
params->sw_mtu = new_mtu;
- set_mtu_cb(priv);
+ if (set_mtu_cb)
+ set_mtu_cb(priv);
netdev->mtu = params->sw_mtu;
goto out;
}
--
2.17.0
^ permalink raw reply related
* [pull request][net 0/4] Mellanox, mlx5 fixes 2018-07-31
From: Saeed Mahameed @ 2018-07-31 20:29 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Saeed Mahameed
Hi Dave,
The following series includes four mlx5 fixes.
Please pull and let me know if there's any problem.
For -stable v4.14
net/mlx5e: E-Switch, Initialize eswitch only if eswitch manager
For -stable v4.16
net/mlx5e: Set port trust mode to PCP as default
For -stable v4.17
net/mlx5e: IPoIB, Set the netdevice sw mtu in ipoib enhanced flow
Thanks,
Saeed.
The following changes since commit 6751e7c66cb8689491b89fe02c71d1d44394412b:
net: dsa: mv88e6xxx: Fix SERDES support on 88E6141/6341 (2018-07-31 10:36:59 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux.git tags/mlx5-fixes-2018-07-31
for you to fetch changes up to 8e1d162d8e81838119de18b4ca1e302ce906f2a6:
net/mlx5e: IPoIB, Set the netdevice sw mtu in ipoib enhanced flow (2018-07-31 12:58:45 -0700)
----------------------------------------------------------------
mlx5-fixes-2018-07-31
----------------------------------------------------------------
Adi Nissim (1):
net/mlx5e: Fix null pointer access when setting MTU of vport representor
Eli Cohen (1):
net/mlx5e: E-Switch, Initialize eswitch only if eswitch manager
Feras Daoud (1):
net/mlx5e: IPoIB, Set the netdevice sw mtu in ipoib enhanced flow
Or Gerlitz (1):
net/mlx5e: Set port trust mode to PCP as default
drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c | 2 ++
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 3 ++-
drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 4 ++--
drivers/net/ethernet/mellanox/mlx5/core/ipoib/ipoib.c | 4 ++++
4 files changed, 10 insertions(+), 3 deletions(-)
^ permalink raw reply
* [net 1/4] net/mlx5e: E-Switch, Initialize eswitch only if eswitch manager
From: Saeed Mahameed @ 2018-07-31 20:29 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Eli Cohen, Saeed Mahameed
In-Reply-To: <20180731202959.32729-1-saeedm@mellanox.com>
From: Eli Cohen <eli@mellanox.com>
Execute mlx5_eswitch_init() only if we have MLX5_ESWITCH_MANAGER
capabilities.
Do the same for mlx5_eswitch_cleanup().
Fixes: a9f7705ffd66 ("net/mlx5: Unify vport manager capability check")
Signed-off-by: Eli Cohen <eli@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
index dd01ad4c0b54..40dba9e8af92 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
@@ -1696,7 +1696,7 @@ int mlx5_eswitch_init(struct mlx5_core_dev *dev)
int vport_num;
int err;
- if (!MLX5_VPORT_MANAGER(dev))
+ if (!MLX5_ESWITCH_MANAGER(dev))
return 0;
esw_info(dev,
@@ -1765,7 +1765,7 @@ int mlx5_eswitch_init(struct mlx5_core_dev *dev)
void mlx5_eswitch_cleanup(struct mlx5_eswitch *esw)
{
- if (!esw || !MLX5_VPORT_MANAGER(esw->dev))
+ if (!esw || !MLX5_ESWITCH_MANAGER(esw->dev))
return;
esw_info(esw->dev, "cleanup\n");
--
2.17.0
^ permalink raw reply related
* Re: [PATCH v1 3/3] net: WireGuard secure network tunnel
From: Stephen Hemminger @ 2018-07-31 20:27 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: linux-kernel, netdev, davem, Greg KH
In-Reply-To: <20180731191102.2434-4-Jason@zx2c4.com>
On Tue, 31 Jul 2018 21:11:02 +0200
"Jason A. Donenfeld" <Jason@zx2c4.com> wrote:
> +#define push(stack, p, len) ({ \
> + if (rcu_access_pointer(p)) { \
> + BUG_ON(len >= 128); \
> + stack[len++] = rcu_dereference_protected(p, lockdep_is_held(lock)); \
> + } \
> + true; \
> +})
> +static void free_root_node(struct allowedips_node __rcu *top, struct mutex *lock)
> +{
> + struct allowedips_node *stack[128], *node;
> + unsigned int len;
> +
> + for (len = 0, push(stack, top, len); len > 0 && (node = stack[--len]) && push(stack, node->bit[0], len) && push(stack, node->bit[1], len);)
> + call_rcu_bh(&node->rcu, node_free_rcu);
> +}
This looks like you are doing traversal to free a tree. The stack is there so that you do the rcu callbacks
in the proper order. Won't this create an lot of RCU work at once?
^ permalink raw reply
* Re: [PATCH RFC net-next] openvswitch: Queue upcalls to userspace in per-port round-robin order
From: Ben Pfaff @ 2018-07-31 22:06 UTC (permalink / raw)
To: Matteo Croce
Cc: dev-yBygre7rU0TnMu66kgdUjQ, jpettit-pghWNbHTmq7QT0dZR+AlfA,
netdev, Jiri Benc, Stefano Brivio
In-Reply-To: <CAGnkfhyxQSz=8OsgTsjR3NfZ2FPwv+FjPZNPEY5VHZRsEiQ68w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Jul 31, 2018 at 07:43:34PM +0000, Matteo Croce wrote:
> On Mon, Jul 16, 2018 at 4:54 PM Matteo Croce <mcroce-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> >
> > On Tue, Jul 10, 2018 at 6:31 PM Pravin Shelar <pshelar-LZ6Gd1LRuIk@public.gmane.org> wrote:
> > >
> > > On Wed, Jul 4, 2018 at 7:23 AM, Matteo Croce <mcroce-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > > > From: Stefano Brivio <sbrivio-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > > >
> > > > Open vSwitch sends to userspace all received packets that have
> > > > no associated flow (thus doing an "upcall"). Then the userspace
> > > > program creates a new flow and determines the actions to apply
> > > > based on its configuration.
> > > >
> > > > When a single port generates a high rate of upcalls, it can
> > > > prevent other ports from dispatching their own upcalls. vswitchd
> > > > overcomes this problem by creating many netlink sockets for each
> > > > port, but it quickly exceeds any reasonable maximum number of
> > > > open files when dealing with huge amounts of ports.
> > > >
> > > > This patch queues all the upcalls into a list, ordering them in
> > > > a per-port round-robin fashion, and schedules a deferred work to
> > > > queue them to userspace.
> > > >
> > > > The algorithm to queue upcalls in a round-robin fashion,
> > > > provided by Stefano, is based on these two rules:
> > > > - upcalls for a given port must be inserted after all the other
> > > > occurrences of upcalls for the same port already in the queue,
> > > > in order to avoid out-of-order upcalls for a given port
> > > > - insertion happens once the highest upcall count for any given
> > > > port (excluding the one currently at hand) is greater than the
> > > > count for the port we're queuing to -- if this condition is
> > > > never true, upcall is queued at the tail. This results in a
> > > > per-port round-robin order.
> > > >
> > > > In order to implement a fair round-robin behaviour, a variable
> > > > queueing delay is introduced. This will be zero if the upcalls
> > > > rate is below a given threshold, and grows linearly with the
> > > > queue utilisation (i.e. upcalls rate) otherwise.
> > > >
> > > > This ensures fairness among ports under load and with few
> > > > netlink sockets.
> > > >
> > > Thanks for the patch.
> > > This patch is adding following overhead for upcall handling:
> > > 1. kmalloc.
> > > 2. global spin-lock.
> > > 3. context switch to single worker thread.
> > > I think this could become bottle neck on most of multi core systems.
> > > You have mentioned issue with existing fairness mechanism, Can you
> > > elaborate on those, I think we could improve that before implementing
> > > heavy weight fairness in upcall handling.
> >
> > Hi Pravin,
> >
> > vswitchd allocates N * P netlink sockets, where N is the number of
> > online CPU cores, and P the number of ports.
> > With some setups, this number can grow quite fast, also exceeding the
> > system maximum file descriptor limit.
> > I've seen a 48 core server failing with -EMFILE when trying to create
> > more than 65535 netlink sockets needed for handling 1800+ ports.
> >
> > I made a previous attempt to reduce the sockets to one per CPU, but
> > this was discussed and rejected on ovs-dev because it would remove
> > fairness among ports[1].
> > I think that the current approach of opening a huge number of sockets
> > doesn't really work, (it doesn't scale for sure), it still needs some
> > queueing logic (either in kernel or user space) if we really want to
> > be sure that low traffic ports gets their upcalls quota when other
> > ports are doing way more traffic.
> >
> > If you are concerned about the kmalloc or spinlock, we can solve them
> > with kmem_cache or two copies of the list and rcu, I'll happy to
> > discuss the implementation details, as long as we all agree that the
> > current implementation doesn't scale well and has an issue.
> >
> > [1] https://mail.openvswitch.org/pipermail/ovs-dev/2018-February/344279.html
> >
> > --
> > Matteo Croce
> > per aspera ad upstream
>
> Hi all,
>
> any idea on how to solve the file descriptor limit hit by the netlink sockets?
> I see this issue happen very often, and raising the FD limit to 400k
> seems not the right way to solve it.
> Any other suggestion on how to improve the patch, or solve the problem
> in a different way?
This is an awkward problem to try to solve with sockets because of the
nature of sockets, which are strictly first-in first-out. What you
really want is something closer to the algorithm that we use in
ovs-vswitchd to send packets to an OpenFlow controller. When the
channel becomes congested, then for each packet to be sent to the
controller, OVS appends it to a queue associated with its input port.
(This could be done on a more granular basis than just port.) If the
maximum amount of queued packets is reached, then OVS discards a packet
from the longest queue. When space becomes available in the channel,
OVS round-robins through the queues to send a packet. This achieves
pretty good fairness but it can't be done with sockets because you can't
drop a packet that is already queued to one.
My current thought is that any fairness scheme we implement directly in
the kernel is going to need to evolve over time. Maybe we could do
something flexible with BPF and maps, instead of hard-coding it.
^ permalink raw reply
* Re: [PATCH v1 3/3] net: WireGuard secure network tunnel
From: Stephen Hemminger @ 2018-07-31 20:22 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: linux-kernel, netdev, davem, Greg KH
In-Reply-To: <20180731191102.2434-4-Jason@zx2c4.com>
On Tue, 31 Jul 2018 21:11:02 +0200
"Jason A. Donenfeld" <Jason@zx2c4.com> wrote:
> +static int walk_by_peer(struct allowedips_node __rcu *top, u8 bits, struct allowedips_cursor *cursor, struct wireguard_peer *peer, int (*func)(void *ctx, const u8 *ip, u8 cidr, int family), void *ctx, struct mutex *lock)
> +{
Please break lines at something reasonable like 100 characters.
^ permalink raw reply
* Re: [PATCH v2] Add BPF_SYNCHRONIZE_MAPS bpf(2) command
From: Joel Fernandes @ 2018-07-31 21:56 UTC (permalink / raw)
To: Y Song
Cc: Joel Fernandes, Alexei Starovoitov, Daniel Colascione, LKML,
Tim Murray, Network Development, Lorenzo Colitti, Chenbo Feng,
Mathieu Desnoyers, Alexei Starovoitov, Daniel Borkmann
In-Reply-To: <CAH3MdRU5nn5g0bexrLWU3-UrxSJfrVF0-A2v2VJGAeBDKY=+Zg@mail.gmail.com>
On Mon, Jul 30, 2018 at 09:03:18PM -0700, Y Song wrote:
> On Mon, Jul 30, 2018 at 7:06 PM, Joel Fernandes <joel@joelfernandes.org> wrote:
> > On Mon, Jul 30, 2018 at 07:01:22PM -0700, Joel Fernandes wrote:
> >> On Sun, Jul 29, 2018 at 06:51:18PM +0300, Alexei Starovoitov wrote:
> >> > On Thu, Jul 26, 2018 at 7:51 PM, Daniel Colascione <dancol@google.com> wrote:
> >> > > BPF_SYNCHRONIZE_MAPS waits for the release of any references to a BPF
> >> > > map made by a BPF program that is running at the time the
> >> > > BPF_SYNCHRONIZE_MAPS command is issued. The purpose of this command is
> >> > > to provide a means for userspace to replace a BPF map with another,
> >> > > newer version, then ensure that no component is still using the "old"
> >> > > map before manipulating the "old" map in some way.
> >> > >
> >> > > Signed-off-by: Daniel Colascione <dancol@google.com>
> >> > > ---
> >> > > include/uapi/linux/bpf.h | 9 +++++++++
> >> > > kernel/bpf/syscall.c | 13 +++++++++++++
> >> > > 2 files changed, 22 insertions(+)
> >> > >
> >> > > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> >> > > index b7db3261c62d..5b27e9117d3e 100644
> >> > > --- a/include/uapi/linux/bpf.h
> >> > > +++ b/include/uapi/linux/bpf.h
> >> > > @@ -75,6 +75,14 @@ struct bpf_lpm_trie_key {
> >> > > __u8 data[0]; /* Arbitrary size */
> >> > > };
> >> > >
> >> > > +/* BPF_SYNCHRONIZE_MAPS waits for the release of any references to a
> >> > > + * BPF map made by a BPF program that is running at the time the
> >> > > + * BPF_SYNCHRONIZE_MAPS command is issued. The purpose of this command
> >> >
> >> > that doesn't sound right to me.
> >> > such command won't wait for the release of the references.
> >> > in case of map-in-map the program does not hold
> >> > the references to inner map (only to outer map).
> >>
> >> I didn't follow this completely.
> >>
> >> The userspace program is using the inner map per your description of the
> >> algorithm for using map-in-map to solve the race conditions that this patch
> >> is trying to address:
> >>
> >> If you don't mind, I copy-pasted it below from your netdev post:
> >>
> >> if you use map-in-map you don't need extra boolean map.
> >> 0. bpf prog can do
> >> inner_map = lookup(map_in_map, key=0);
> >> lookup(inner_map, your_real_key);
> >> 1. user space writes into map_in_map[0] <- FD of new map
> >> 2. some cpus are using old inner map and some a new
> >> 3. user space does sys_membarrier(CMD_GLOBAL) which will do synchronize_sched()
> >> which in CONFIG_PREEMPT_NONE=y servers is the same as synchronize_rcu()
> >> which will guarantee that progs finished.
> >> 4. scan old inner map
> >>
> >> In step 2, as you mentioned there are CPUs using different inner maps. So
> >> could you clarify how the synchronize_rcu mechanism will even work if you're
> >> now saying "program does not hold references to the inner maps"?
>
> The program only held references to the outer maps, and the outer map
> held references to the inner maps. The user space program can add/remove
> the inner map for a particular outer map while the prog <-> outer-map
> relationship is not changed.
My definition of "reference" in this context is protection by rcu_read_lock.
So I was concerned the above map-in-map access isn't protected as such when
Alexei said "program doesn't have reference on inner map" in the above steps.
Maybe I misunderstood what is the meaning of reference here.
To make the map-in-map thing to work for Chenbo/Lorenzo's usecase, both the
access of outer map at key=0 and the inner map have to protect by
rcu_read_lock so that the membarrier call will work.
So basically step 0 in the steps above should be rcu_read_lock protected to
satisfy Chenbo/Lorenzo's usecase.
I know today the entire program is run as preempt disabled (unless something
changed) so this shouldn't be a problem, but in the future if the verifier is
doing similar things at a finer grainer level, then the above has to be
taken into consideration.
Does that make sense or am I missing something?
thanks,
- Joel
^ permalink raw reply
* Re: KASAN: use-after-free Read in rtnetlink_put_metrics
From: David Miller @ 2018-07-31 21:53 UTC (permalink / raw)
To: sd
Cc: eric.dumazet, syzbot+41f9c04b50ef70c66947, christian.brauner,
dsahern, fw, jbenc, ktkhai, linux-kernel, lucien.xin, netdev,
syzkaller-bugs
In-Reply-To: <20180731134014.GA32114@bistromath.localdomain>
From: Sabrina Dubroca <sd@queasysnail.net>
Date: Tue, 31 Jul 2018 15:40:14 +0200
> 2018-07-31, 05:41:56 -0700, Eric Dumazet wrote:
>> Probably also caused by :
>>
>>
>> commit df18b50448fab1dff093731dfd0e25e77e1afcd1
>> Author: Sabrina Dubroca <sd@queasysnail.net>
>> Date: Mon Jul 30 16:23:10 2018 +0200
>>
>> net/ipv6: fix metrics leak
>
> Yeah, I'm looking into both those reports :/
Please get me a fix for this soon, because as you can imagine this is
going to hold up the 4.18 release.
Thanks.
^ permalink raw reply
* [PATCH ghak90 (was ghak32) V4 10/10] debug audit: read container ID of a process
From: Richard Guy Briggs @ 2018-07-31 20:07 UTC (permalink / raw)
To: containers, linux-api, Linux-Audit Mailing List, linux-fsdevel,
LKML, netdev, netfilter-devel
Cc: luto, carlos, viro, dhowells, simo, eparis, serge, ebiederm,
Richard Guy Briggs
In-Reply-To: <cover.1533065887.git.rgb@redhat.com>
Add support for reading the audit container identifier from the proc
filesystem.
This is a read from the proc entry of the form
/proc/PID/audit_containerid where PID is the process ID of the task
whose audit container identifier is sought.
The read expects up to a u64 value (unset: 18446744073709551615).
This read requires CAP_AUDIT_CONTROL.
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
Acked-by: Serge Hallyn <serge@hallyn.com>
---
fs/proc/base.c | 23 +++++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 1b3cda1..95fc64a 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -1261,6 +1261,24 @@ static ssize_t proc_sessionid_read(struct file * file, char __user * buf,
.llseek = generic_file_llseek,
};
+static ssize_t proc_contid_read(struct file *file, char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ struct inode *inode = file_inode(file);
+ struct task_struct *task = get_proc_task(inode);
+ ssize_t length;
+ char tmpbuf[TMPBUFLEN*2];
+
+ if (!task)
+ return -ESRCH;
+ /* if we don't have caps, reject */
+ if (!capable(CAP_AUDIT_CONTROL))
+ return -EPERM;
+ length = scnprintf(tmpbuf, TMPBUFLEN*2, "%llu", audit_get_contid(task));
+ put_task_struct(task);
+ return simple_read_from_buffer(buf, count, ppos, tmpbuf, length);
+}
+
static ssize_t proc_contid_write(struct file *file, const char __user *buf,
size_t count, loff_t *ppos)
{
@@ -1291,6 +1309,7 @@ static ssize_t proc_contid_write(struct file *file, const char __user *buf,
}
static const struct file_operations proc_contid_operations = {
+ .read = proc_contid_read,
.write = proc_contid_write,
.llseek = generic_file_llseek,
};
@@ -2987,7 +3006,7 @@ static int proc_pid_patch_state(struct seq_file *m, struct pid_namespace *ns,
#ifdef CONFIG_AUDITSYSCALL
REG("loginuid", S_IWUSR|S_IRUGO, proc_loginuid_operations),
REG("sessionid", S_IRUGO, proc_sessionid_operations),
- REG("audit_containerid", S_IWUSR, proc_contid_operations),
+ REG("audit_containerid", S_IWUSR|S_IRUSR, proc_contid_operations),
#endif
#ifdef CONFIG_FAULT_INJECTION
REG("make-it-fail", S_IRUGO|S_IWUSR, proc_fault_inject_operations),
@@ -3373,7 +3392,7 @@ static int proc_tid_comm_permission(struct inode *inode, int mask)
#ifdef CONFIG_AUDITSYSCALL
REG("loginuid", S_IWUSR|S_IRUGO, proc_loginuid_operations),
REG("sessionid", S_IRUGO, proc_sessionid_operations),
- REG("audit_containerid", S_IWUSR, proc_contid_operations),
+ REG("audit_containerid", S_IWUSR|S_IRUSR, proc_contid_operations),
#endif
#ifdef CONFIG_FAULT_INJECTION
REG("make-it-fail", S_IRUGO|S_IWUSR, proc_fault_inject_operations),
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH 1/4] treewide: convert ISO_8859-1 text comments to utf-8
From: Rob Herring @ 2018-07-31 21:49 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Andrew Morton, Joe Perches, Samuel Ortiz, David S. Miller,
Michael Ellerman, Jonathan Cameron, linux-wireless, netdev,
devicetree, linux-kernel, linux-arm-kernel, linux-crypto,
linuxppc-dev, linux-iio, linux-pm, lvs-devel, netfilter-devel,
coreteam
In-Reply-To: <20180724111600.4158975-1-arnd@arndb.de>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 1690 bytes --]
On Tue, Jul 24, 2018 at 01:13:25PM +0200, Arnd Bergmann wrote:
> Almost all files in the kernel are either plain text or UTF-8
> encoded. A couple however are ISO_8859-1, usually just a few
> characters in a C comments, for historic reasons.
>
> This converts them all to UTF-8 for consistency.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> .../devicetree/bindings/net/nfc/pn544.txt | 2 +-
> arch/arm/boot/dts/sun4i-a10-inet97fv2.dts | 2 +-
> arch/arm/crypto/sha256_glue.c | 2 +-
> arch/arm/crypto/sha256_neon_glue.c | 4 +-
> drivers/crypto/vmx/ghashp8-ppc.pl | 12 +-
> drivers/iio/dac/ltc2632.c | 2 +-
> drivers/power/reset/ltc2952-poweroff.c | 4 +-
> kernel/events/callchain.c | 2 +-
> net/netfilter/ipvs/Kconfig | 8 +-
> net/netfilter/ipvs/ip_vs_mh.c | 4 +-
> tools/power/cpupower/po/de.po | 44 +++----
> tools/power/cpupower/po/fr.po | 120 +++++++++---------
> 12 files changed, 103 insertions(+), 103 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/nfc/pn544.txt b/Documentation/devicetree/bindings/net/nfc/pn544.txt
> index 538a86f7b2b0..72593f056b75 100644
> --- a/Documentation/devicetree/bindings/net/nfc/pn544.txt
> +++ b/Documentation/devicetree/bindings/net/nfc/pn544.txt
> @@ -2,7 +2,7 @@
>
> Required properties:
> - compatible: Should be "nxp,pn544-i2c".
> -- clock-frequency: I²C work frequency.
> +- clock-frequency: I²C work frequency.
I'd prefer just plain ASCII 'I2C' here, but either way:
Acked-by: Rob Herring <robh@kernel.org>
Rob
^ permalink raw reply
* Re: [PATCH v1 3/3] net: WireGuard secure network tunnel
From: Andrew Lunn @ 2018-07-31 20:02 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: linux-kernel, netdev, davem, Greg KH
In-Reply-To: <20180731191102.2434-4-Jason@zx2c4.com>
Hi Jason
I just gave this patch to checkpatch.pl...
total: 6 errors, 763 warnings, 6514 lines checked
It would be good to reduce these numbers.
> +static __always_inline void swap_endian(u8 *dst, const u8 *src, u8 bits)
There is a general preference to not force the compile to
inline. Leave it to decide.
> +#define push(stack, p, len) ({ \
> + if (rcu_access_pointer(p)) { \
> + BUG_ON(len >= 128); \
> + stack[len++] = rcu_dereference_protected(p, lockdep_is_held(lock)); \
> + } \
> + true; \
> +})
> +#undef push
> +
> +#define push(p) ({ BUG_ON(len >= 128); stack[len++] = p; })
This is going to lead to bugs, coders thinking push() does one thing,
when it actually does something else. I would suggest making these
helper functions, with useful names.
> +/* Returns a strong reference to a peer */
> +static __always_inline struct wireguard_peer *lookup(struct allowedips_node __rcu *root, u8 bits, const void *be_ip)
> +{
> + struct wireguard_peer *peer = NULL;
> + struct allowedips_node *node;
> + u8 ip[16] __aligned(__alignof(u64));
netdev code requires that all local variables are in reverse christmas tree.
Andrew
^ permalink raw reply
* Re: [PATCH RFC net-next] openvswitch: Queue upcalls to userspace in per-port round-robin order
From: Matteo Croce @ 2018-07-31 19:43 UTC (permalink / raw)
To: Pravin B Shelar, jpettit, gvrose8192, Ben Pfaff
Cc: netdev, dev, Stefano Brivio, Jiri Benc, Aaron
In-Reply-To: <CAGnkfhwS3J=7W7BQabFXSLLad3dV3YfocDf9qADaWqqgZKPB7g@mail.gmail.com>
On Mon, Jul 16, 2018 at 4:54 PM Matteo Croce <mcroce@redhat.com> wrote:
>
> On Tue, Jul 10, 2018 at 6:31 PM Pravin Shelar <pshelar@ovn.org> wrote:
> >
> > On Wed, Jul 4, 2018 at 7:23 AM, Matteo Croce <mcroce@redhat.com> wrote:
> > > From: Stefano Brivio <sbrivio@redhat.com>
> > >
> > > Open vSwitch sends to userspace all received packets that have
> > > no associated flow (thus doing an "upcall"). Then the userspace
> > > program creates a new flow and determines the actions to apply
> > > based on its configuration.
> > >
> > > When a single port generates a high rate of upcalls, it can
> > > prevent other ports from dispatching their own upcalls. vswitchd
> > > overcomes this problem by creating many netlink sockets for each
> > > port, but it quickly exceeds any reasonable maximum number of
> > > open files when dealing with huge amounts of ports.
> > >
> > > This patch queues all the upcalls into a list, ordering them in
> > > a per-port round-robin fashion, and schedules a deferred work to
> > > queue them to userspace.
> > >
> > > The algorithm to queue upcalls in a round-robin fashion,
> > > provided by Stefano, is based on these two rules:
> > > - upcalls for a given port must be inserted after all the other
> > > occurrences of upcalls for the same port already in the queue,
> > > in order to avoid out-of-order upcalls for a given port
> > > - insertion happens once the highest upcall count for any given
> > > port (excluding the one currently at hand) is greater than the
> > > count for the port we're queuing to -- if this condition is
> > > never true, upcall is queued at the tail. This results in a
> > > per-port round-robin order.
> > >
> > > In order to implement a fair round-robin behaviour, a variable
> > > queueing delay is introduced. This will be zero if the upcalls
> > > rate is below a given threshold, and grows linearly with the
> > > queue utilisation (i.e. upcalls rate) otherwise.
> > >
> > > This ensures fairness among ports under load and with few
> > > netlink sockets.
> > >
> > Thanks for the patch.
> > This patch is adding following overhead for upcall handling:
> > 1. kmalloc.
> > 2. global spin-lock.
> > 3. context switch to single worker thread.
> > I think this could become bottle neck on most of multi core systems.
> > You have mentioned issue with existing fairness mechanism, Can you
> > elaborate on those, I think we could improve that before implementing
> > heavy weight fairness in upcall handling.
>
> Hi Pravin,
>
> vswitchd allocates N * P netlink sockets, where N is the number of
> online CPU cores, and P the number of ports.
> With some setups, this number can grow quite fast, also exceeding the
> system maximum file descriptor limit.
> I've seen a 48 core server failing with -EMFILE when trying to create
> more than 65535 netlink sockets needed for handling 1800+ ports.
>
> I made a previous attempt to reduce the sockets to one per CPU, but
> this was discussed and rejected on ovs-dev because it would remove
> fairness among ports[1].
> I think that the current approach of opening a huge number of sockets
> doesn't really work, (it doesn't scale for sure), it still needs some
> queueing logic (either in kernel or user space) if we really want to
> be sure that low traffic ports gets their upcalls quota when other
> ports are doing way more traffic.
>
> If you are concerned about the kmalloc or spinlock, we can solve them
> with kmem_cache or two copies of the list and rcu, I'll happy to
> discuss the implementation details, as long as we all agree that the
> current implementation doesn't scale well and has an issue.
>
> [1] https://mail.openvswitch.org/pipermail/ovs-dev/2018-February/344279.html
>
> --
> Matteo Croce
> per aspera ad upstream
Hi all,
any idea on how to solve the file descriptor limit hit by the netlink sockets?
I see this issue happen very often, and raising the FD limit to 400k
seems not the right way to solve it.
Any other suggestion on how to improve the patch, or solve the problem
in a different way?
Regards,
^ permalink raw reply
* Re: [PATCH] netlink: Fix spectre v1 gadget in netlink_create()
From: Josh Poimboeuf @ 2018-07-31 21:23 UTC (permalink / raw)
To: Jeremy Cline; +Cc: David S . Miller, netdev, linux-kernel
In-Reply-To: <20180731211316.12971-1-jcline@redhat.com>
On Tue, Jul 31, 2018 at 09:13:16PM +0000, Jeremy Cline wrote:
> 'protocol' is a user-controlled value, so sanitize it after the bounds
> check to avoid using it for speculative out-of-bounds access to arrays
> indexed by it.
>
> This addresses the following accesses detected with the help of smatch:
>
> * net/netlink/af_netlink.c:654 __netlink_create() warn: potential
> spectre issue 'nlk_cb_mutex_keys' [w]
>
> * net/netlink/af_netlink.c:654 __netlink_create() warn: potential
> spectre issue 'nlk_cb_mutex_key_strings' [w]
>
> * net/netlink/af_netlink.c:685 netlink_create() warn: potential spectre
> issue 'nl_table' [w] (local cap)
>
> Cc: Josh Poimboeuf <jpoimboe@redhat.com>
> Signed-off-by: Jeremy Cline <jcline@redhat.com>
Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
--
Josh
^ permalink raw reply
* Mobile apps development
From: Vivek Shah @ 2018-07-31 8:33 UTC (permalink / raw)
To: netdev
We are an image editing service provider having more than 10 years of
industry experience.
We use latest techniques for photo editing to meet international quality
standards.
We are committed to deliver reliable photo processing services.
Production of 1000+ images within single working day
24×7×365 photo editing services
On-demand image editing to meet rush job requirements
Service details:
Images Masking
Photo Clipping Path
Photo Cutout
Photo Enhancement
Vector Conversion
Photo Stitching Services
Fashion Photo Editing
Jewelry Retouching
Footwear Photo Editing
Furniture Photo Retouching
Wedding Photo Editing
Real Estate Photo Editing
Photo Restoration
We provide trials to evaluate our service quality to new clients.
Thanks,
Edward
^ permalink raw reply
* [PATCH] netlink: Fix spectre v1 gadget in netlink_create()
From: Jeremy Cline @ 2018-07-31 21:13 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, linux-kernel, Jeremy Cline, Josh Poimboeuf
'protocol' is a user-controlled value, so sanitize it after the bounds
check to avoid using it for speculative out-of-bounds access to arrays
indexed by it.
This addresses the following accesses detected with the help of smatch:
* net/netlink/af_netlink.c:654 __netlink_create() warn: potential
spectre issue 'nlk_cb_mutex_keys' [w]
* net/netlink/af_netlink.c:654 __netlink_create() warn: potential
spectre issue 'nlk_cb_mutex_key_strings' [w]
* net/netlink/af_netlink.c:685 netlink_create() warn: potential spectre
issue 'nl_table' [w] (local cap)
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Jeremy Cline <jcline@redhat.com>
---
net/netlink/af_netlink.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 393573a99a5a..59dac45ad452 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -63,6 +63,7 @@
#include <linux/hash.h>
#include <linux/genetlink.h>
#include <linux/net_namespace.h>
+#include <linux/nospec.h>
#include <net/net_namespace.h>
#include <net/netns/generic.h>
@@ -679,6 +680,7 @@ static int netlink_create(struct net *net, struct socket *sock, int protocol,
if (protocol < 0 || protocol >= MAX_LINKS)
return -EPROTONOSUPPORT;
+ protocol = array_index_nospec(protocol, MAX_LINKS);
netlink_lock_table();
#ifdef CONFIG_MODULES
--
2.17.1
^ permalink raw reply related
* RE: linux-next: manual merge of the net-next tree with the rdma tree
From: Parav Pandit @ 2018-07-31 21:12 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Jason Gunthorpe, David Miller, Networking, Doug Ledford,
Linux-Next Mailing List, Linux Kernel Mailing List, Ursula Braun,
Leon Romanovsky, linux-rdma@vger.kernel.org
In-Reply-To: <20180727150903.0f2816ba@canb.auug.org.au>
Hi Stephen,
> -----Original Message-----
> From: linux-rdma-owner@vger.kernel.org <linux-rdma-owner@vger.kernel.org>
> On Behalf Of Stephen Rothwell
> Sent: Friday, July 27, 2018 12:09 AM
> To: Parav Pandit <parav@mellanox.com>
> Cc: Jason Gunthorpe <jgg@mellanox.com>; David Miller
> <davem@davemloft.net>; Networking <netdev@vger.kernel.org>; Doug
> Ledford <dledford@redhat.com>; Linux-Next Mailing List <linux-
> next@vger.kernel.org>; Linux Kernel Mailing List <linux-
> kernel@vger.kernel.org>; Ursula Braun <ubraun@linux.ibm.com>; Leon
> Romanovsky <leonro@mellanox.com>; linux-rdma@vger.kernel.org
> Subject: Re: linux-next: manual merge of the net-next tree with the rdma tree
>
> Hi Parav,
>
> On Fri, 27 Jul 2018 04:57:41 +0000 Parav Pandit <parav@mellanox.com> wrote:
> >
> > > for (i = 0; i < smcibdev->pattr[ibport - 1].gid_tbl_len; i++) {
> > > - memset(&_gid, 0, SMC_GID_SIZE);
> > > - memset(&gattr, 0, sizeof(gattr));
> > > - if (ib_query_gid(smcibdev->ibdev, ibport, i, &_gid, &gattr))
> > > + gattr = rdma_get_gid_attr(smcibdev->ibdev, ibport, i);
> > > + if (IS_ERR(gattr))
> > > continue;
> > > - if (!gattr.ndev)
> > > + if (!gattr->ndev)
> > > continue;
> > This requires a small fix.
> > If (!gattr->ndev {
> > rdma_put_gid_attr(gattr);
> > continue;
> > }
>
> Thanks, I have fixed this up for Monday.
You might want to consider this compatibility patch in Linux-rdma tree to avoid a merge conflict of smc.
https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/commit/?h=for-next&id=7aaa1807e698f73094b78f0ef25b1a37a4409a55
^ permalink raw reply
* Re: [PATCH] lib/bpf/libbpf: Simplify the code by using PTR_ERR_OR_ZERO
From: Daniel Borkmann @ 2018-07-31 21:11 UTC (permalink / raw)
To: zhong jiang, ast, davem; +Cc: netdev, linux-kernel
In-Reply-To: <1533054656-36134-1-git-send-email-zhongjiang@huawei.com>
On 07/31/2018 06:30 PM, zhong jiang wrote:
> Use PTR_ERR_OR_ZERO is better than the open code.
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
> ---
> tools/lib/bpf/libbpf.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 40211b5..9b61468 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -2271,9 +2271,7 @@ struct bpf_map *
>
> long libbpf_get_error(const void *ptr)
> {
> - if (IS_ERR(ptr))
> - return PTR_ERR(ptr);
> - return 0;
> + return PTR_ERR_OR_ZERO(ptr);
> }
>
> int bpf_prog_load(const char *file, enum bpf_prog_type type,
>
Looks like you didn't even bother to try to compile your change ...
# make
Warning: Kernel ABI header at 'tools/include/uapi/linux/if_link.h' differs from latest version at 'include/uapi/linux/if_link.h'
CC libbpf.o
CC nlattr.o
CC btf.o
CC bpf.o
CC libbpf_errno.o
libbpf.c: In function ‘libbpf_get_error’:
libbpf.c:2269:9: error: implicit declaration of function ‘PTR_ERR_OR_ZERO’ [-Werror=implicit-function-declaration]
return PTR_ERR_OR_ZERO(ptr);
^~~~~~~~~~~~~~~
libbpf.c:2269:2: error: nested extern declaration of ‘PTR_ERR_OR_ZERO’ [-Werror=nested-externs]
return PTR_ERR_OR_ZERO(ptr);
^~~~~~
cc1: all warnings being treated as errors
^ permalink raw reply
* [PATCH net-next v1] net: add helpers checking if socket can be bound to nonlocal address
From: Vincent Bernat @ 2018-07-31 19:18 UTC (permalink / raw)
To: David Miller, kuznet, yoshfuji, netdev, tom; +Cc: Vincent Bernat
In-Reply-To: <20180730.090841.1368485183443140606.davem@davemloft.net>
The construction "net->ipv4.sysctl_ip_nonlocal_bind || inet->freebind
|| inet->transparent" is present three times and its IPv6 counterpart
is also present three times. We introduce two small helpers to
characterize these tests uniformly.
Signed-off-by: Vincent Bernat <vincent@bernat.im>
---
include/net/inet_sock.h | 8 ++++++++
include/net/ipv6.h | 7 +++++++
net/ipv4/af_inet.c | 3 +--
net/ipv4/ping.c | 6 ++----
net/ipv6/af_inet6.c | 6 ++----
net/ipv6/datagram.c | 3 +--
6 files changed, 21 insertions(+), 12 deletions(-)
diff --git a/include/net/inet_sock.h b/include/net/inet_sock.h
index 314be484c696..e03b93360f33 100644
--- a/include/net/inet_sock.h
+++ b/include/net/inet_sock.h
@@ -359,4 +359,12 @@ static inline bool inet_get_convert_csum(struct sock *sk)
return !!inet_sk(sk)->convert_csum;
}
+
+static inline bool inet_can_nonlocal_bind(struct net *net,
+ struct inet_sock *inet)
+{
+ return net->ipv4.sysctl_ip_nonlocal_bind ||
+ inet->freebind || inet->transparent;
+}
+
#endif /* _INET_SOCK_H */
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index a44509f4e985..82deb684ba73 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -766,6 +766,13 @@ static inline int ip6_sk_dst_hoplimit(struct ipv6_pinfo *np, struct flowi6 *fl6,
return hlimit;
}
+static inline bool ipv6_can_nonlocal_bind(struct net *net,
+ struct inet_sock *inet)
+{
+ return net->ipv6.sysctl.ip_nonlocal_bind ||
+ inet->freebind || inet->transparent;
+}
+
/* copy IPv6 saddr & daddr to flow_keys, possibly using 64bit load/store
* Equivalent to : flow->v6addrs.src = iph->saddr;
* flow->v6addrs.dst = iph->daddr;
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index f2a0a3bab6b5..ee707b91d1a7 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -486,8 +486,7 @@ int __inet_bind(struct sock *sk, struct sockaddr *uaddr, int addr_len,
* is temporarily down)
*/
err = -EADDRNOTAVAIL;
- if (!net->ipv4.sysctl_ip_nonlocal_bind &&
- !(inet->freebind || inet->transparent) &&
+ if (!inet_can_nonlocal_bind(net, inet) &&
addr->sin_addr.s_addr != htonl(INADDR_ANY) &&
chk_addr_ret != RTN_LOCAL &&
chk_addr_ret != RTN_MULTICAST &&
diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
index b54c964ad925..8d7aaf118a30 100644
--- a/net/ipv4/ping.c
+++ b/net/ipv4/ping.c
@@ -320,8 +320,7 @@ static int ping_check_bind_addr(struct sock *sk, struct inet_sock *isk,
if (addr->sin_addr.s_addr == htonl(INADDR_ANY))
chk_addr_ret = RTN_LOCAL;
- if ((net->ipv4.sysctl_ip_nonlocal_bind == 0 &&
- isk->freebind == 0 && isk->transparent == 0 &&
+ if ((!inet_can_nonlocal_bind(net, isk) &&
chk_addr_ret != RTN_LOCAL) ||
chk_addr_ret == RTN_MULTICAST ||
chk_addr_ret == RTN_BROADCAST)
@@ -361,8 +360,7 @@ static int ping_check_bind_addr(struct sock *sk, struct inet_sock *isk,
scoped);
rcu_read_unlock();
- if (!(net->ipv6.sysctl.ip_nonlocal_bind ||
- isk->freebind || isk->transparent || has_addr ||
+ if (!(ipv6_can_nonlocal_bind(net, isk) || has_addr ||
addr_type == IPV6_ADDR_ANY))
return -EADDRNOTAVAIL;
diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index c9535354149f..020f6e14a7af 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -322,8 +322,7 @@ static int __inet6_bind(struct sock *sk, struct sockaddr *uaddr, int addr_len,
/* Reproduce AF_INET checks to make the bindings consistent */
v4addr = addr->sin6_addr.s6_addr32[3];
chk_addr_ret = inet_addr_type(net, v4addr);
- if (!net->ipv4.sysctl_ip_nonlocal_bind &&
- !(inet->freebind || inet->transparent) &&
+ if (!inet_can_nonlocal_bind(net, inet) &&
v4addr != htonl(INADDR_ANY) &&
chk_addr_ret != RTN_LOCAL &&
chk_addr_ret != RTN_MULTICAST &&
@@ -362,8 +361,7 @@ static int __inet6_bind(struct sock *sk, struct sockaddr *uaddr, int addr_len,
*/
v4addr = LOOPBACK4_IPV6;
if (!(addr_type & IPV6_ADDR_MULTICAST)) {
- if (!net->ipv6.sysctl.ip_nonlocal_bind &&
- !(inet->freebind || inet->transparent) &&
+ if (!ipv6_can_nonlocal_bind(net, inet) &&
!ipv6_chk_addr(net, &addr->sin6_addr,
dev, 0)) {
err = -EADDRNOTAVAIL;
diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
index c46936563b15..b0123af1492d 100644
--- a/net/ipv6/datagram.c
+++ b/net/ipv6/datagram.c
@@ -800,8 +800,7 @@ int ip6_datagram_send_ctl(struct net *net, struct sock *sk,
if (addr_type != IPV6_ADDR_ANY) {
int strict = __ipv6_addr_src_scope(addr_type) <= IPV6_ADDR_SCOPE_LINKLOCAL;
- if (!(net->ipv6.sysctl.ip_nonlocal_bind ||
- inet_sk(sk)->freebind || inet_sk(sk)->transparent) &&
+ if (!ipv6_can_nonlocal_bind(net, inet_sk(sk)) &&
!ipv6_chk_addr_and_flags(net, &src_info->ipi6_addr,
dev, !strict, 0,
IFA_F_TENTATIVE) &&
--
2.18.0
^ permalink raw reply related
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