* [PATCH] net/packet: fix missing net_device reference release
From: Douglas Caetano dos Santos @ 2017-05-12 18:19 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Eric Dumazet, Daniel Borkmann, Willem de Bruijn,
Jarno Rajahalme, Andrey Konovalov, Anoob Soman, Sowmini Varadhan,
Philip Pettersson, Mike Rapoport
When using a TX ring buffer, if an error occurs processing a control
message (e.g. invalid message), the net_device reference is not
released.
Fixes c14ac9451c348 ("sock: enable timestamping using control messages")
Signed-off-by: Douglas Caetano dos Santos <douglascs@taghos.com.br>
---
net/packet/af_packet.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index f4001763134d..e3eeed19cc7a 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -2658,13 +2658,6 @@ static int tpacket_snd(struct packet_sock *po, struct msghdr *msg)
dev = dev_get_by_index(sock_net(&po->sk), saddr->sll_ifindex);
}
- sockc.tsflags = po->sk.sk_tsflags;
- if (msg->msg_controllen) {
- err = sock_cmsg_send(&po->sk, msg, &sockc);
- if (unlikely(err))
- goto out;
- }
-
err = -ENXIO;
if (unlikely(dev == NULL))
goto out;
@@ -2672,6 +2665,13 @@ static int tpacket_snd(struct packet_sock *po, struct msghdr *msg)
if (unlikely(!(dev->flags & IFF_UP)))
goto out_put;
+ sockc.tsflags = po->sk.sk_tsflags;
+ if (msg->msg_controllen) {
+ err = sock_cmsg_send(&po->sk, msg, &sockc);
+ if (unlikely(err))
+ goto out_put;
+ }
+
if (po->sk.sk_socket->type == SOCK_RAW)
reserve = dev->hard_header_len;
size_max = po->tx_ring.frame_size
--
2.12.2
^ permalink raw reply related
* Re: [Patch net] ipv4: restore rt->fi for reference counting
From: Cong Wang @ 2017-05-12 17:49 UTC (permalink / raw)
To: Eric Dumazet
Cc: Julian Anastasov, David Miller, Linux Kernel Network Developers,
Andrey Konovalov, Eric Dumazet
In-Reply-To: <1494564948.7796.128.camel@edumazet-glaptop3.roam.corp.google.com>
On Thu, May 11, 2017 at 9:55 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2017-05-11 at 18:22 -0700, Cong Wang wrote:
>> On Thu, May 11, 2017 at 5:07 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>> > So, if I understand you correctly it is safe to NULL'ing
>> > nh_dev in NETDEV_UNREGISTER_FINAL, right?
>> >
>> > If still not, how about transfer nh_dev's to loopback_dev
>> > too in NETDEV_UNREGISTER? Like we transfer dst->dev.
>> >
>> > I don't want to touch the fast path to check for NULL, as
>> > it will change more code and slow down performance.
>>
>> Finally I come up with the attached patch. Please let me know if
>> I still miss anything.
>
> You have not addressed my prior feedback, unless I am mistaken ?
>
> fib_route_seq_show() and others do not expect fi->fib_dev suddenly
> becoming NULL.
>
> RCU contract is more complicated than simply adding rcu grace period
> before delete.
>
If you mean the lack of rcu_dereference() in fib_route_seq_show() ,
yeah, I don't fix it because I think it should be in a separate patch,
it is not this patch which introduces RCU to nh_dev as I explained
previously.
Or you mean anything else?
^ permalink raw reply
* Re: [PATCH] net: ipv6: Truncate single route when it doesn't fit into dump buffer.
From: David Miller @ 2017-05-12 17:34 UTC (permalink / raw)
To: dsahern; +Cc: mq, netdev, linux-kernel, dsa, kuznet, jmorris, yoshfuji, kaber
In-Reply-To: <3828cf04-1bf8-92d2-dfc4-184bd615fe10@gmail.com>
From: David Ahern <dsahern@gmail.com>
Date: Fri, 12 May 2017 10:26:08 -0700
> On 5/12/17 8:24 AM, David Miller wrote:
>> From: Jan Moskyto Matejka <mq@ucw.cz>
>> Date: Fri, 12 May 2017 13:15:10 +0200
>>
>>> -int rt6_dump_route(struct rt6_info *rt, void *p_arg);
>>> +int rt6_dump_route(struct rt6_info *rt, void *p_arg, int truncate);
>>
>> Please use "bool" and "true"/"false" for boolean values.
>>
>> What does ipv4 do in this situation?
>>
>> I'm hesitant to be OK with adding a new nlmsg flag just for this case
>> if we solve this problem differently and using existing mechanisms
>> elsewhere.
>>
>
> I'll take a look at this later today or this weekend; we can't just
> truncate the route returned to userspace.
Agreed.
^ permalink raw reply
* alignment of MAP pointers
From: David Miller @ 2017-05-12 17:32 UTC (permalink / raw)
To: daniel; +Cc: ast, alexei.starovoitov, netdev
Daniel, this continues our discussion from yesterday where you
rightly pointed out that map pointers don't have their state
adjusted like packet pointers do currently.
I'm working on a patch sketched below to deal with this.
My understanding is that packet pointers are validated using the
accumulated known offset, plus a strictly seen test against the end of
the packet. Any time the end of the packet is tested against by the
program, we set reg->range to the largest offset against the packet
pointer which we can prove is legal to access.
If we see a non-constant variable added to the packet pointer, we
reset the reg->range value because we don't have a proven test
against the end of the packet any longer.
And this is now where all of the auxiliary offset and alignment stuff
is factored into things as well.
For MAP_VALUE_ADJ pointers, the min-max logic applies here. We know
the legal range of offsets for the map value accesses, and the min/max
values make sure the program stays within that range.
So I think what I'm doing below should make that logic still work
properly. We run check_map_ptr_add() only when we would have
considered the pointer to be still of type PTR_TO_MAP_VALUE_ADJ
(otherwise it gets marked as UNKNOWN). So the only side effects we
will have to these kinds of pointers is:
1) Advance reg->off
2) When variable is added:
a) Allocate reg->id
b) set reg->aux_off to reg->off
c) clear reg->off
d) clear reg->range (not used by map pointers)
So it mostly should be fine since we leave the min/max values alone.
When check_map_access_adj() does it's work, it takes into consideration
only the min/max values and the offset from the load/store instruction.
Anyways, your feedback is appreciated.
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 39f2dcb..e95adb3 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -823,10 +823,31 @@ static int check_pkt_ptr_alignment(const struct bpf_reg_state *reg,
}
static int check_val_ptr_alignment(const struct bpf_reg_state *reg,
- int size, bool strict)
+ int off, int size, bool strict)
{
- if (strict && size != 1) {
- verbose("Unknown alignment. Only byte-sized access allowed in value access.\n");
+ int reg_off;
+
+ /* Byte size accesses are always allowed. */
+ if (!strict || size == 1)
+ return 0;
+
+ reg_off = reg->off;
+ if (reg->id) {
+ if (reg->aux_off_align % size) {
+ verbose("Value access is only %u byte aligned, %d byte access not allowed\n",
+ reg->aux_off_align, size);
+ return -EACCES;
+ }
+ reg_off += reg->aux_off;
+ }
+
+ /* skb->data is NET_IP_ALIGN-ed, but for strict alignment checking
+ * we force this to 2 which is universally what architectures use
+ * when they don't set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS.
+ */
+ if ((reg_off + off) % size != 0) {
+ verbose("misaligned value access off %d+%d size %d\n",
+ reg_off, off, size);
return -EACCES;
}
@@ -846,7 +867,7 @@ static int check_ptr_alignment(struct bpf_verifier_env *env,
case PTR_TO_PACKET:
return check_pkt_ptr_alignment(reg, off, size, strict);
case PTR_TO_MAP_VALUE_ADJ:
- return check_val_ptr_alignment(reg, size, strict);
+ return check_val_ptr_alignment(reg, off, size, strict);
default:
if (off % size != 0) {
verbose("misaligned access off %d size %d\n",
@@ -1458,8 +1479,8 @@ static int check_call(struct bpf_verifier_env *env, int func_id, int insn_idx)
return 0;
}
-static int check_packet_ptr_add(struct bpf_verifier_env *env,
- struct bpf_insn *insn)
+static int check_pointer_add(struct bpf_verifier_env *env,
+ struct bpf_insn *insn, bool is_packet)
{
struct bpf_reg_state *regs = env->cur_state.regs;
struct bpf_reg_state *dst_reg = ®s[insn->dst_reg];
@@ -1468,28 +1489,30 @@ static int check_packet_ptr_add(struct bpf_verifier_env *env,
s32 imm;
if (BPF_SRC(insn->code) == BPF_K) {
- /* pkt_ptr += imm */
+ /* pointer += imm */
imm = insn->imm;
add_imm:
- if (imm < 0) {
- verbose("addition of negative constant to packet pointer is not allowed\n");
- return -EACCES;
- }
- if (imm >= MAX_PACKET_OFF ||
- imm + dst_reg->off >= MAX_PACKET_OFF) {
- verbose("constant %d is too large to add to packet pointer\n",
- imm);
- return -EACCES;
+ if (is_packet) {
+ if (imm < 0) {
+ verbose("addition of negative constant to packet pointer is not allowed\n");
+ return -EACCES;
+ }
+ if (imm >= MAX_PACKET_OFF ||
+ imm + dst_reg->off >= MAX_PACKET_OFF) {
+ verbose("constant %d is too large to add to packet pointer\n",
+ imm);
+ return -EACCES;
+ }
}
- /* a constant was added to pkt_ptr.
+ /* a constant was added to the pointer.
* Remember it while keeping the same 'id'
*/
dst_reg->off += imm;
} else {
bool had_id;
- if (src_reg->type == PTR_TO_PACKET) {
+ if (is_packet && src_reg->type == PTR_TO_PACKET) {
/* R6=pkt(id=0,off=0,r=62) R7=imm22; r7 += r6 */
tmp_reg = *dst_reg; /* save r7 state */
*dst_reg = *src_reg; /* copy pkt_ptr state r6 into r7 */
@@ -1503,21 +1526,21 @@ static int check_packet_ptr_add(struct bpf_verifier_env *env,
}
if (src_reg->type == CONST_IMM) {
- /* pkt_ptr += reg where reg is known constant */
+ /* pointer += reg where reg is known constant */
imm = src_reg->imm;
goto add_imm;
}
- /* disallow pkt_ptr += reg
+ /* disallow pointer += reg
* if reg is not uknown_value with guaranteed zero upper bits
- * otherwise pkt_ptr may overflow and addition will become
+ * otherwise pointer_ptr may overflow and addition will become
* subtraction which is not allowed
*/
if (src_reg->type != UNKNOWN_VALUE) {
- verbose("cannot add '%s' to ptr_to_packet\n",
+ verbose("cannot add '%s' to pointer\n",
reg_type_str[src_reg->type]);
return -EACCES;
}
- if (src_reg->imm < 48) {
+ if (is_packet && src_reg->imm < 48) {
verbose("cannot add integer value with %lld upper zero bits to ptr_to_packet\n",
src_reg->imm);
return -EACCES;
@@ -1525,12 +1548,12 @@ static int check_packet_ptr_add(struct bpf_verifier_env *env,
had_id = (dst_reg->id != 0);
- /* dst_reg stays as pkt_ptr type and since some positive
+ /* dst_reg stays as the same type and since some positive
* integer value was added to the pointer, increment its 'id'
*/
dst_reg->id = ++env->id_gen;
- /* something was added to pkt_ptr, set range to zero */
+ /* something was added to pointer, set range to zero */
dst_reg->aux_off += dst_reg->off;
dst_reg->off = 0;
dst_reg->range = 0;
@@ -1543,6 +1566,18 @@ static int check_packet_ptr_add(struct bpf_verifier_env *env,
return 0;
}
+static int check_packet_ptr_add(struct bpf_verifier_env *env,
+ struct bpf_insn *insn)
+{
+ return check_pointer_add(env, insn, true);
+}
+
+static int check_map_ptr_add(struct bpf_verifier_env *env,
+ struct bpf_insn *insn)
+{
+ return check_pointer_add(env, insn, false);
+}
+
static int evaluate_reg_alu(struct bpf_verifier_env *env, struct bpf_insn *insn)
{
struct bpf_reg_state *regs = env->cur_state.regs;
@@ -2056,10 +2091,12 @@ static int check_alu_op(struct bpf_verifier_env *env, struct bpf_insn *insn)
if (env->allow_ptr_leaks &&
BPF_CLASS(insn->code) == BPF_ALU64 && opcode == BPF_ADD &&
(dst_reg->type == PTR_TO_MAP_VALUE ||
- dst_reg->type == PTR_TO_MAP_VALUE_ADJ))
+ dst_reg->type == PTR_TO_MAP_VALUE_ADJ)) {
dst_reg->type = PTR_TO_MAP_VALUE_ADJ;
- else
+ check_map_ptr_add(env, insn);
+ } else {
mark_reg_unknown_value(regs, insn->dst_reg);
+ }
}
return 0;
^ permalink raw reply related
* Re: [Patch net] ipv4: restore rt->fi for reference counting
From: Cong Wang @ 2017-05-12 17:27 UTC (permalink / raw)
To: Julian Anastasov
Cc: Eric Dumazet, David Miller, Linux Kernel Network Developers,
Andrey Konovalov, Eric Dumazet
In-Reply-To: <alpine.LFD.2.20.1705120659370.1811@ja.home.ssi.bg>
On Thu, May 11, 2017 at 11:39 PM, Julian Anastasov <ja@ssi.bg> wrote:
>
> Hello,
>
> On Thu, 11 May 2017, Cong Wang wrote:
>
>> On Thu, May 11, 2017 at 5:07 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>> > So, if I understand you correctly it is safe to NULL'ing
>> > nh_dev in NETDEV_UNREGISTER_FINAL, right?
>> >
>> > If still not, how about transfer nh_dev's to loopback_dev
>> > too in NETDEV_UNREGISTER? Like we transfer dst->dev.
>> >
>> > I don't want to touch the fast path to check for NULL, as
>> > it will change more code and slow down performance.
>>
>> Finally I come up with the attached patch. Please let me know if
>> I still miss anything.
>
> fib_flush will unlink the FIB infos at NETDEV_UNREGISTER
> time, so we can not see them in any hash tables later on
> NETDEV_UNREGISTER_FINAL. fib_put_nh_devs() can not work
> except if moving NHs in another hash table but that should
> not be needed.
Ah, I did miss the hlist_del() in fib_table_flush(), so we just need some
way to link those fib_nh together for NETDEV_UNREGISTER_FINAL,
a linked list should be sufficient, but requires adding list_head to fib_nh.
>
> I'm thinking for the following solution which
> is a bit hackish:
>
> - on NETDEV_UNREGISTER we want to put the nh_dev references,
> so fib_release_info is a good place. But as fib_release_info
> is not always called, we will have two places that put
> references. We can use such hack:
>
> - for example, use nh_oif to know if dev_put is
> already called
>
> - fib_release_info() should set nh_oif to 0 because
> it will now call dev_put without clearing nh_dev
Are you sure we are safe to call dev_put() in fib_release_info()
for _all_ paths, especially non-unregister paths? See:
commit e49cc0da7283088c5e03d475ffe2fdcb24a6d5b1
Author: Yanmin Zhang <yanmin_zhang@linux.intel.com>
Date: Wed May 23 15:39:45 2012 +0000
ipv4: fix the rcu race between free_fib_info and ip_route_output_slow
But, hmm, very interesting, I always thought dev_put() triggers a
kfree() potentially, but here your suggestion actually leverages the fact
that it is merely a pcpu counter decrease, so for unregister path,
this is just giving refcnt back, which means it is safe as long as
we don't have any parallel unregister? We should because of RTNL.
I see why you say this is hackish, really it is. ;) We have to ensure
the evil dev_put() is only called on unregister path.
>
> - free_fib_info_rcu() will not call dev_put if nh_oif is 0:
> if (nexthop_nh->nh_dev && nexthop_nh->nh_oif)
> dev_put(nexthop_nh->nh_dev);
>
> - as fi is unlinked, there is no chance fib_info_hashfn()
> to use the cleared nh_oif for hashing
>
> - we expect noone to touch nh_dev fields after fi is
> unlinked, this includes free_fib_info and free_fib_info_rcu
>
> What we achieve:
>
> - between NETDEV_UNREGISTER and NETDEV_UNREGISTER_FINAL nh_dev
> still points to our dev (and not to loopback, I think, this
> answers your question in previous email), so route lookups
> will not find loopback in the FIB tree. We do not want
> some packets to be wrongly rerouted. Even if we don't
> hold dev reference, the RCU grace period helps here.
Thanks to dev_put() for not calling a netdev_freemem(). ;-)
>
> - fib_dev/nh_dev != NULL checks are not needed, so this addresses
> Eric's concerns. BTW, fib_route_seq_show actually checks
> for fi->fib_dev, may be not in a safe way (lockless_dereference
> needed?) but as we don't set nh_dev to NULL this is not
> needed.
>
I think Eric was complaining about the lack of rcu_dereference()
there.
> What more? What about nh_pcpu_rth_output and
> nh_rth_input holding routes? We should think about
> them too. I should think more if nh_oif trick can work
> for them, may be not because nh_oif is optional...
> May be we should purge them somehow?
>
Or maybe don't touch nh_oif but using a new flag in
nh_flags?? We only need to know if we should call
dev_put() in free_fib_info_rcu().
Again, I am still not sure if it is any better than just
putting these fib_nh into a linked list.
Thanks.
^ permalink raw reply
* Re: [PATCH] net: ipv6: Truncate single route when it doesn't fit into dump buffer.
From: David Ahern @ 2017-05-12 17:26 UTC (permalink / raw)
To: David Miller, mq
Cc: netdev, linux-kernel, dsa, kuznet, jmorris, yoshfuji, kaber
In-Reply-To: <20170512.112447.1421545301592945998.davem@davemloft.net>
On 5/12/17 8:24 AM, David Miller wrote:
> From: Jan Moskyto Matejka <mq@ucw.cz>
> Date: Fri, 12 May 2017 13:15:10 +0200
>
>> -int rt6_dump_route(struct rt6_info *rt, void *p_arg);
>> +int rt6_dump_route(struct rt6_info *rt, void *p_arg, int truncate);
>
> Please use "bool" and "true"/"false" for boolean values.
>
> What does ipv4 do in this situation?
>
> I'm hesitant to be OK with adding a new nlmsg flag just for this case
> if we solve this problem differently and using existing mechanisms
> elsewhere.
>
I'll take a look at this later today or this weekend; we can't just
truncate the route returned to userspace.
^ permalink raw reply
* [PATCH V2 net 1/1] smc: switch to usage of IB_PD_UNSAFE_GLOBAL_RKEY
From: Ursula Braun @ 2017-05-12 17:09 UTC (permalink / raw)
To: davem
Cc: hch, netdev, linux-rdma, linux-s390, jwi, schwidefsky,
heiko.carstens, raspl, ubraun
In-Reply-To: <20170512170952.39863-1-ubraun@linux.vnet.ibm.com>
This patch makes users aware of the current security implications
when using smc.
The final fix to resolve the reported security issue is worked on;
respective patches will follow as soon as possible.
Signed-off-by: Ursula Braun <ubraun@linux.vnet.ibm.com>
---
net/smc/smc_clc.c | 4 ++--
net/smc/smc_core.c | 16 +++-------------
net/smc/smc_core.h | 2 +-
net/smc/smc_ib.c | 21 ++-------------------
net/smc/smc_ib.h | 2 --
5 files changed, 8 insertions(+), 37 deletions(-)
diff --git a/net/smc/smc_clc.c b/net/smc/smc_clc.c
index e41f594..03ec058 100644
--- a/net/smc/smc_clc.c
+++ b/net/smc/smc_clc.c
@@ -204,7 +204,7 @@ int smc_clc_send_confirm(struct smc_sock *smc)
memcpy(&cclc.lcl.mac, &link->smcibdev->mac[link->ibport - 1], ETH_ALEN);
hton24(cclc.qpn, link->roce_qp->qp_num);
cclc.rmb_rkey =
- htonl(conn->rmb_desc->mr_rx[SMC_SINGLE_LINK]->rkey);
+ htonl(conn->rmb_desc->rkey[SMC_SINGLE_LINK]);
cclc.conn_idx = 1; /* for now: 1 RMB = 1 RMBE */
cclc.rmbe_alert_token = htonl(conn->alert_token_local);
cclc.qp_mtu = min(link->path_mtu, link->peer_mtu);
@@ -256,7 +256,7 @@ int smc_clc_send_accept(struct smc_sock *new_smc, int srv_first_contact)
memcpy(&aclc.lcl.mac, link->smcibdev->mac[link->ibport - 1], ETH_ALEN);
hton24(aclc.qpn, link->roce_qp->qp_num);
aclc.rmb_rkey =
- htonl(conn->rmb_desc->mr_rx[SMC_SINGLE_LINK]->rkey);
+ htonl(conn->rmb_desc->rkey[SMC_SINGLE_LINK]);
aclc.conn_idx = 1; /* as long as 1 RMB = 1 RMBE */
aclc.rmbe_alert_token = htonl(conn->alert_token_local);
aclc.qp_mtu = link->path_mtu;
diff --git a/net/smc/smc_core.c b/net/smc/smc_core.c
index 65020e9..3ac09a6 100644
--- a/net/smc/smc_core.c
+++ b/net/smc/smc_core.c
@@ -613,19 +613,8 @@ int smc_rmb_create(struct smc_sock *smc)
rmb_desc = NULL;
continue; /* if mapping failed, try smaller one */
}
- rc = smc_ib_get_memory_region(lgr->lnk[SMC_SINGLE_LINK].roce_pd,
- IB_ACCESS_REMOTE_WRITE |
- IB_ACCESS_LOCAL_WRITE,
- &rmb_desc->mr_rx[SMC_SINGLE_LINK]);
- if (rc) {
- smc_ib_buf_unmap(lgr->lnk[SMC_SINGLE_LINK].smcibdev,
- tmp_bufsize, rmb_desc,
- DMA_FROM_DEVICE);
- kfree(rmb_desc->cpu_addr);
- kfree(rmb_desc);
- rmb_desc = NULL;
- continue;
- }
+ rmb_desc->rkey[SMC_SINGLE_LINK] =
+ lgr->lnk[SMC_SINGLE_LINK].roce_pd->unsafe_global_rkey;
rmb_desc->used = 1;
write_lock_bh(&lgr->rmbs_lock);
list_add(&rmb_desc->list,
@@ -668,6 +657,7 @@ int smc_rmb_rtoken_handling(struct smc_connection *conn,
for (i = 0; i < SMC_RMBS_PER_LGR_MAX; i++) {
if ((lgr->rtokens[i][SMC_SINGLE_LINK].rkey == rkey) &&
+ (lgr->rtokens[i][SMC_SINGLE_LINK].dma_addr == dma_addr) &&
test_bit(i, lgr->rtokens_used_mask)) {
conn->rtoken_idx = i;
return 0;
diff --git a/net/smc/smc_core.h b/net/smc/smc_core.h
index 27eb3805..b013cb4 100644
--- a/net/smc/smc_core.h
+++ b/net/smc/smc_core.h
@@ -93,7 +93,7 @@ struct smc_buf_desc {
u64 dma_addr[SMC_LINKS_PER_LGR_MAX];
/* mapped address of buffer */
void *cpu_addr; /* virtual address of buffer */
- struct ib_mr *mr_rx[SMC_LINKS_PER_LGR_MAX];
+ u32 rkey[SMC_LINKS_PER_LGR_MAX];
/* for rmb only:
* rkey provided to peer
*/
diff --git a/net/smc/smc_ib.c b/net/smc/smc_ib.c
index cb69ab9..b317155 100644
--- a/net/smc/smc_ib.c
+++ b/net/smc/smc_ib.c
@@ -37,24 +37,6 @@ u8 local_systemid[SMC_SYSTEMID_LEN] = SMC_LOCAL_SYSTEMID_RESET; /* unique system
* identifier
*/
-int smc_ib_get_memory_region(struct ib_pd *pd, int access_flags,
- struct ib_mr **mr)
-{
- int rc;
-
- if (*mr)
- return 0; /* already done */
-
- /* obtain unique key -
- * next invocation of get_dma_mr returns a different key!
- */
- *mr = pd->device->get_dma_mr(pd, access_flags);
- rc = PTR_ERR_OR_ZERO(*mr);
- if (IS_ERR(*mr))
- *mr = NULL;
- return rc;
-}
-
static int smc_ib_modify_qp_init(struct smc_link *lnk)
{
struct ib_qp_attr qp_attr;
@@ -210,7 +192,8 @@ int smc_ib_create_protection_domain(struct smc_link *lnk)
{
int rc;
- lnk->roce_pd = ib_alloc_pd(lnk->smcibdev->ibdev, 0);
+ lnk->roce_pd = ib_alloc_pd(lnk->smcibdev->ibdev,
+ IB_PD_UNSAFE_GLOBAL_RKEY);
rc = PTR_ERR_OR_ZERO(lnk->roce_pd);
if (IS_ERR(lnk->roce_pd))
lnk->roce_pd = NULL;
diff --git a/net/smc/smc_ib.h b/net/smc/smc_ib.h
index 7e1f0e2..b567152 100644
--- a/net/smc/smc_ib.h
+++ b/net/smc/smc_ib.h
@@ -61,8 +61,6 @@ void smc_ib_dealloc_protection_domain(struct smc_link *lnk);
int smc_ib_create_protection_domain(struct smc_link *lnk);
void smc_ib_destroy_queue_pair(struct smc_link *lnk);
int smc_ib_create_queue_pair(struct smc_link *lnk);
-int smc_ib_get_memory_region(struct ib_pd *pd, int access_flags,
- struct ib_mr **mr);
int smc_ib_ready_link(struct smc_link *lnk);
int smc_ib_modify_qp_rts(struct smc_link *lnk);
int smc_ib_modify_qp_reset(struct smc_link *lnk);
--
2.10.2
^ permalink raw reply related
* [PATCH V2 net 0/1] net/smc and the RDMA core
From: Ursula Braun @ 2017-05-12 17:09 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: hch-jcswGhMUV9g, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-s390-u79uwXL29TY76Z2rM5mHXA,
jwi-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
schwidefsky-tA70FqPdS9bQT0dZR+AlfA,
heiko.carstens-tA70FqPdS9bQT0dZR+AlfA,
raspl-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
ubraun-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
From: Ursula Braun <ursula.braun-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
Hi Dave,
yesterday I included a patch proposal into a response to Christoph Hellwig,
which is now already seen here:
http://patchwork.ozlabs.org/patch/761250/
Christoph suggested an additional improvement not to use __internal_mr.
Thus I come up with this improved version V2.
Kind regards, Ursula
Ursula Braun (1):
smc: switch to usage of IB_PD_UNSAFE_GLOBAL_RKEY
net/smc/smc_clc.c | 4 ++--
net/smc/smc_core.c | 16 +++-------------
net/smc/smc_core.h | 2 +-
net/smc/smc_ib.c | 21 ++-------------------
net/smc/smc_ib.h | 2 --
5 files changed, 8 insertions(+), 37 deletions(-)
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net] sfc: revert changes to NIC revision numbers
From: David Miller @ 2017-05-12 16:34 UTC (permalink / raw)
To: ecree; +Cc: linux-net-drivers, netdev
In-Reply-To: <5a87b5cf-1696-0fbc-209d-95fa85023918@solarflare.com>
From: Edward Cree <ecree@solarflare.com>
Date: Fri, 12 May 2017 17:18:50 +0100
> From: Bert Kenward <bkenward@solarflare.com>
>
> The revision enum values (eg EFX_REV_HUNT_A0) form part of our API,
> and are included in ethtool. If these are inconsistent then ethtool
> will print garbage for a register dump (ethtool -d).
>
> Fixes: 5a6681e22c14 ("sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver")
> Signed-off-by: Edward Cree <ecree@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH] vmxnet3: ensure that adapter is in proper state during force_close
From: David Miller @ 2017-05-12 16:24 UTC (permalink / raw)
To: nhorman; +Cc: netdev, skhare, pv-drivers
In-Reply-To: <20170512160001.24425-1-nhorman@tuxdriver.com>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Fri, 12 May 2017 12:00:01 -0400
> There are several paths in vmxnet3, where settings changes cause the
> adapter to be brought down and back up (vmxnet3_set_ringparam among
> them). Should part of the reset operation fail, these paths call
> vmxnet3_force_close, which enables all napi instances prior to calling
> dev_close (with the expectation that vmxnet3_close will then properly
> disable them again). However, vmxnet3_force_close neglects to clear
> VMXNET3_STATE_BIT_QUIESCED prior to calling dev_close. As a result
> vmxnet3_quiesce_dev (called from vmxnet3_close), returns early, and
> leaves all the napi instances in a enabled state while the device itself
> is closed. If a device in this state is activated again, napi_enable
> will be called on already enabled napi_instances, leading to a BUG halt.
>
> The fix is to simply enausre that the QUIESCED bit is cleared in
> vmxnet3_force_close to allow quesence to be completed properly on close.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Looks good, applied, thanks Neil.
^ permalink raw reply
* Re: [PATCH] mdio: mux: fix device_node_continue.cocci warnings
From: David Miller @ 2017-05-12 16:22 UTC (permalink / raw)
To: julia.lawall
Cc: netdev, jon.mason, andrew, f.fainelli, kbuild-all, linux-kernel
In-Reply-To: <alpine.DEB.2.20.1705122252440.3416@hadrien>
From: Julia Lawall <julia.lawall@lip6.fr>
Date: Fri, 12 May 2017 22:54:23 +0800 (SGT)
> Device node iterators put the previous value of the index variable, so an
> explicit put causes a double put.
...
> @@ -169,7 +169,6 @@ int mdio_mux_init(struct device *dev,
> if (r) {
> mdiobus_free(cb->mii_bus);
> devm_kfree(dev, cb);
> - of_node_put(child_bus_node);
> } else {
I think we're instead simply missing a break; statement here.
^ permalink raw reply
* Re: [PATCH net-next] tools: hv: Add clean up for included files in Ubuntu net config
From: David Miller @ 2017-05-12 16:20 UTC (permalink / raw)
To: haiyangz, haiyangz; +Cc: netdev, kys, olaf, vkuznets, linux-kernel
In-Reply-To: <1494598413-19106-1-git-send-email-haiyangz@exchange.microsoft.com>
From: Haiyang Zhang <haiyangz@exchange.microsoft.com>
Date: Fri, 12 May 2017 07:13:33 -0700
>
> + local fn
> + for fn in "${fnlist[@]}"
> + do
> awk "/$nic_end/{x=0} x{next} /$nic_start/{x=1;next} 1" $fn >$tmpfl
>
> cp $tmpfl $fn
> + done
Please indent the body of this loop properly.
^ permalink raw reply
* [PATCH net] sfc: revert changes to NIC revision numbers
From: Edward Cree @ 2017-05-12 16:18 UTC (permalink / raw)
To: linux-net-drivers, davem; +Cc: netdev
From: Bert Kenward <bkenward@solarflare.com>
The revision enum values (eg EFX_REV_HUNT_A0) form part of our API,
and are included in ethtool. If these are inconsistent then ethtool
will print garbage for a register dump (ethtool -d).
Fixes: 5a6681e22c14 ("sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver")
Signed-off-by: Edward Cree <ecree@solarflare.com>
---
drivers/net/ethernet/sfc/nic.h | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/sfc/nic.h b/drivers/net/ethernet/sfc/nic.h
index 7b916aa..4d7fb8a 100644
--- a/drivers/net/ethernet/sfc/nic.h
+++ b/drivers/net/ethernet/sfc/nic.h
@@ -18,8 +18,12 @@
#include "mcdi.h"
enum {
- EFX_REV_SIENA_A0 = 0,
- EFX_REV_HUNT_A0 = 1,
+ /* Revisions 0-2 were Falcon A0, A1 and B0 respectively.
+ * They are not supported by this driver but these revision numbers
+ * form part of the ethtool API for register dumping.
+ */
+ EFX_REV_SIENA_A0 = 3,
+ EFX_REV_HUNT_A0 = 4,
};
static inline int efx_nic_rev(struct efx_nic *efx)
^ permalink raw reply related
* Re: [PATCH] net: ch9200: add missing USB-descriptor endianness conversions
From: David Miller @ 2017-05-12 16:16 UTC (permalink / raw)
To: johan; +Cc: linux-usb, netdev
In-Reply-To: <20170512101326.2029-1-johan@kernel.org>
From: Johan Hovold <johan@kernel.org>
Date: Fri, 12 May 2017 12:13:26 +0200
> Add the missing endianness conversions to a debug statement printing
> the USB device-descriptor idVendor and idProduct fields during probe.
>
> Signed-off-by: Johan Hovold <johan@kernel.org>
Applied.
^ permalink raw reply
* Re: [PATCH] net: irda: irda-usb: fix firmware name on big-endian hosts
From: David Miller @ 2017-05-12 16:16 UTC (permalink / raw)
To: johan; +Cc: samuel, netdev, stable, nfedchik
In-Reply-To: <20170512101113.1935-1-johan@kernel.org>
From: Johan Hovold <johan@kernel.org>
Date: Fri, 12 May 2017 12:11:13 +0200
> Add missing endianness conversion when using the USB device-descriptor
> bcdDevice field to construct a firmware file name.
>
> Fixes: 8ef80aef118e ("[IRDA]: irda-usb.c: STIR421x cleanups")
> Cc: stable <stable@vger.kernel.org> # 2.6.18
> Cc: Nick Fedchik <nfedchik@atlantic-link.com.ua>
> Signed-off-by: Johan Hovold <johan@kernel.org>
Applied.
^ permalink raw reply
* Re: [PATCH] net: dsa: mv88e6xxx: add default case to switch
From: David Miller @ 2017-05-12 16:15 UTC (permalink / raw)
To: garsilva; +Cc: andrew, vivien.didelot, f.fainelli, netdev, linux-kernel
In-Reply-To: <20170512031129.GA4065@embeddedgus>
From: "Gustavo A. R. Silva" <garsilva@embeddedor.com>
Date: Thu, 11 May 2017 22:11:29 -0500
> Add default case to switch in order to avoid any chance of using an
> uninitialized variable _low_, in case s->type does not match any of
> the listed case values.
>
> Addresses-Coverity-ID: 1398130
> Suggested-by: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Applied, thanks.
^ permalink raw reply
* Re: [net 1/6] net/mlx5e: Use a spinlock to synchronize statistics
From: David Miller @ 2017-05-12 16:13 UTC (permalink / raw)
To: saeedm; +Cc: netdev, galp, kernel-team
In-Reply-To: <20170512115650.11635-2-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Fri, 12 May 2017 14:56:45 +0300
> From: Gal Pressman <galp@mellanox.com>
>
> Add a spinlock to prevent races when querying statistics, for example
> querying counters in the middle of a non atomic memcpy() operation in
> mlx5e_update_stats().
>
> This RW lock should be held when accessing priv->stats, to prevent other
> reads/writes.
>
> Fixes: 9218b44dcc05 ("net/mlx5e: Statistics handling refactoring")
> Signed-off-by: Gal Pressman <galp@mellanox.com>
> Suggested-by: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: kernel-team@fb.com
> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
This is overkill, and that rwlock is going to show up in perf for some
workloads.
Furthermore, two kzalloc()'s for a single state update operation?
That's not reasonable either.
Use a seqlock, which is the primitive for handling this kind of
situation cheaply, and adds no atomics to the read path.
Thank you.
^ permalink raw reply
* 48683 netdev
From: mari.kayhko @ 2017-05-12 16:02 UTC (permalink / raw)
To: netdev
[-- Attachment #1: 829.zip --]
[-- Type: application/zip, Size: 1985 bytes --]
^ permalink raw reply
* [PATCH] vmxnet3: ensure that adapter is in proper state during force_close
From: Neil Horman @ 2017-05-12 16:00 UTC (permalink / raw)
To: netdev; +Cc: Neil Horman, Shrikrishna Khare, VMware, Inc., David S. Miller
There are several paths in vmxnet3, where settings changes cause the
adapter to be brought down and back up (vmxnet3_set_ringparam among
them). Should part of the reset operation fail, these paths call
vmxnet3_force_close, which enables all napi instances prior to calling
dev_close (with the expectation that vmxnet3_close will then properly
disable them again). However, vmxnet3_force_close neglects to clear
VMXNET3_STATE_BIT_QUIESCED prior to calling dev_close. As a result
vmxnet3_quiesce_dev (called from vmxnet3_close), returns early, and
leaves all the napi instances in a enabled state while the device itself
is closed. If a device in this state is activated again, napi_enable
will be called on already enabled napi_instances, leading to a BUG halt.
The fix is to simply enausre that the QUIESCED bit is cleared in
vmxnet3_force_close to allow quesence to be completed properly on close.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Shrikrishna Khare <skhare@vmware.com>
CC: "VMware, Inc." <pv-drivers@vmware.com>
CC: "David S. Miller" <davem@davemloft.net>
---
drivers/net/vmxnet3/vmxnet3_drv.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 25bc764..d1c7029 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -2962,6 +2962,11 @@ vmxnet3_force_close(struct vmxnet3_adapter *adapter)
/* we need to enable NAPI, otherwise dev_close will deadlock */
for (i = 0; i < adapter->num_rx_queues; i++)
napi_enable(&adapter->rx_queue[i].napi);
+ /*
+ * Need to clear the quiesce bit to ensure that vmxnet3_close
+ * can quiesce the device properly
+ */
+ clear_bit(VMXNET3_STATE_BIT_QUIESCED, &adapter->state);
dev_close(adapter->netdev);
}
--
2.9.3
^ permalink raw reply related
* Re: Queries regarding TAP interface
From: Stephen Hemminger @ 2017-05-12 15:52 UTC (permalink / raw)
To: Kashyap, Saurav; +Cc: netdev@vger.kernel.org
In-Reply-To: <C7C039BE-EDC9-4E82-BC66-EEDE814F9E56@cavium.com>
On Fri, 12 May 2017 05:02:37 +0000
"Kashyap, Saurav" <Saurav.Kashyap@cavium.com> wrote:
> Hi,
>
> I am using upstream kernel 4.11.0 and base is RHEL 7.2. I am playing around with TAP devices and created it using following commands
> =======
> ip tuntap add tap10 mode tap
> ip addr add 172.28.12.1/24 dev tap10
> ip link set tap10 up
> ethtool -s tap10 msglvl 1
> =======
>
> I enabled debug in driver and also added some prints in tun_net_xmit function. I tried to ping using tap10 but I don’t see request reaching driver. I also tried to create a bridge using brctl and link with physical ethernet interface but it didn’t work.
>
> Second experiment I did was to create two tap device on same system and try pinging one from another, that also didn’t worked.
> I have following queries
> 1) Is I am missing something?
> 2) Is is possible to hook my own tx/rx to that tap device, so that data packets actually goes on wire?
> 3) Does DHCP works with tap devices?
>
>
> Thanks,
> ~Saurav
>
Don't you need an application reading/writing the tap device?
The carrier state of tap device is up/down based on whether the corresponding tap device is open
^ permalink raw reply
* Re: [PATCH net-next] ipv6: Implement limits on hop by hop and destination options
From: David Miller @ 2017-05-12 15:38 UTC (permalink / raw)
To: tom; +Cc: netdev, kafai
In-Reply-To: <1494451999-19031-1-git-send-email-tom@herbertland.com>
From: Tom Herbert <tom@herbertland.com>
Date: Wed, 10 May 2017 14:33:19 -0700
> RFC 2460 (IPv6) defines hop by hop options and destination options
> extension headers. Both of these carry a list of TLVs which is
> only limited by the maximum length of the extension header (2048
> bytes). By the spec a host must process all the TLVs in these
> options, however these could be used as a fairly obvious
> denial of service attack. I think this could in fact be
> a significant DOS vector on the Internet, one mitigating
> factor might be that many FWs drop all packets with EH (and
> obviously this is only IPv6) so an Internet wide attack might not
> be so effective (yet!).
>
> By my calculation, the worse case packet with TLVs in a standard
> 1500 byte MTU packet that would be processed by the stack contains
> 1282 invidual TLVs (including pad TLVS) or 724 two byte TLVs. I
> wrote a quick test program that floods a whole bunch of these
> packets to a host and sure enough there is substantial time spent
> in ip6_parse_tlv. These packets contain nothing but unknown TLVS
> (that are ignored), TLV padding, and bogus UDP header with zero
> payload length.
...
> Default values are set to 8 for options counts, and set to INT_MAX
> for maximum length. Note the choice to limit options to 8 is an
> arbitrary guess (roughly based on the fact that the stack supports
> three HBH options and just one destination option).
So the maximum number of TLVs we could process is some function of the
option count limit, and the number of padding TLVs that can be stuffed
alongside of those 8 non-padding options?
^ permalink raw reply
* Re: [PATCH] net: ipv6: Truncate single route when it doesn't fit into dump buffer.
From: David Miller @ 2017-05-12 15:24 UTC (permalink / raw)
To: mq; +Cc: netdev, linux-kernel, dsa, kuznet, jmorris, yoshfuji, kaber
In-Reply-To: <20170512111510.2697-1-mq@ucw.cz>
From: Jan Moskyto Matejka <mq@ucw.cz>
Date: Fri, 12 May 2017 13:15:10 +0200
> -int rt6_dump_route(struct rt6_info *rt, void *p_arg);
> +int rt6_dump_route(struct rt6_info *rt, void *p_arg, int truncate);
Please use "bool" and "true"/"false" for boolean values.
What does ipv4 do in this situation?
I'm hesitant to be OK with adding a new nlmsg flag just for this case
if we solve this problem differently and using existing mechanisms
elsewhere.
^ permalink raw reply
* Re: [PATCH net-next] selftests/bpf: get rid of -D__x86_64__
From: Andrew Lunn @ 2017-05-12 15:17 UTC (permalink / raw)
To: David Miller; +Cc: ast, daniel, netdev
In-Reply-To: <20170512.104624.902298156565692816.davem@davemloft.net>
On Fri, May 12, 2017 at 10:46:24AM -0400, David Miller wrote:
> From: Alexei Starovoitov <ast@fb.com>
> Date: Thu, 11 May 2017 22:07:04 -0700
>
> > On 5/11/17 6:29 PM, David Miller wrote:
> >> This whole thing go me thinking however. What do you expect to happen
> >> on 32-bit architectures implementing an eBPF JIT?
> >
> > I doubt any 32-bit cpu architectures will do JIT in the near future.
>
> ARM 32-bit is being implemented as we speak, in fact it's been discussed
> on this very list over the past week.
It could be XDP is interesting on small embedded systems, i.e ARM32
and MIPS, used in WiFi access points and the like. I've heard it said
that the Linux network stack has become too big to run well on these
systems, it no longer fits in the instruction cache. It would be
interesting to see if XDP/eBPF can be used for handling part of the
packet load without thrashing the instruction cache.
Andrew
^ permalink raw reply
* Re: [PATCH 2/4] net: macb: Add tsu_clk to device tree
From: Rob Herring @ 2017-05-12 15:12 UTC (permalink / raw)
To: Rafal Ozieblo
Cc: David Miller, nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w,
Richard Cochran, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
harini.katakam-gjFFaj9aHVfQT0dZR+AlfA,
andrei.pistirica-UWL1GkI3JZL3oGB3hsPCZA
In-Reply-To: <1494322010-15179-1-git-send-email-rafalo-vna1KIf7WgpBDgjK7y7TUQ@public.gmane.org>
On Tue, May 09, 2017 at 10:26:50AM +0100, Rafal Ozieblo wrote:
> Signed-off-by: Rafal Ozieblo <rafalo-vna1KIf7WgpBDgjK7y7TUQ@public.gmane.org>
> ---
> Documentation/devicetree/bindings/net/macb.txt | 1 +
> 1 file changed, 1 insertion(+)
I acked the last version, please add acks when posting new versions.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] mdio: mux: fix device_node_continue.cocci warnings
From: Julia Lawall @ 2017-05-12 14:54 UTC (permalink / raw)
To: netdev, Jon Mason; +Cc: Andrew Lunn, Florian Fainelli, kbuild-all, linux-kernel
Device node iterators put the previous value of the index variable, so an
explicit put causes a double put.
In particular, of_mdiobus_register can fail before doing anything
interesting, so one could view it as a no-op from the reference count
point of view.
Generated by: scripts/coccinelle/iterators/device_node_continue.cocci
CC: Jon Mason <jon.mason@broadcom.com>
Signed-off-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
tree:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
master
head: 8785ded64cfb68b8d8b2583c7c1fc611f99eabf2
commit: b60161668199ac62011c024adc9e66713b9554e7 [13999/14120] mdio: mux:
mdio-mux.c | 1 -
1 file changed, 1 deletion(-)
--- a/drivers/net/phy/mdio-mux.c
+++ b/drivers/net/phy/mdio-mux.c
@@ -169,7 +169,6 @@ int mdio_mux_init(struct device *dev,
if (r) {
mdiobus_free(cb->mii_bus);
devm_kfree(dev, cb);
- of_node_put(child_bus_node);
} else {
cb->next = pb->children;
pb->children = cb;
^ 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