* [PATCH] net: cxgb3_main: fix a missing-check bug
From: Wenwen Wang @ 2018-10-05 13:48 UTC (permalink / raw)
To: Wenwen Wang
Cc: Kangjie Lu, Santosh Raspatur, David S. Miller,
open list:CXGB3 ETHERNET DRIVER (CXGB3), open list
In cxgb_extension_ioctl(), the command of the ioctl is firstly copied from
the user-space buffer 'useraddr' to 'cmd' and checked through the
switch statement. If the command is not as expected, an error code
EOPNOTSUPP is returned. In the following execution, i.e., the cases of the
switch statement, the whole buffer of 'useraddr' is copied again to a
specific data structure, according to what kind of command is requested.
However, after the second copy, there is no re-check on the newly-copied
command. Given that the buffer 'useraddr' is in the user space, a malicious
user can race to change the command between the two copies. By doing so,
the attacker can supply malicious data to the kernel and cause undefined
behavior.
This patch adds a re-check in each case of the switch statement if there is
a second copy in that case, to re-check whether the command obtained in the
second copy is the same as the one in the first copy. If not, an error code
EINVAL is returned.
Signed-off-by: Wenwen Wang <wang6495@umn.edu>
---
drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
index a19172d..c34ea38 100644
--- a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
@@ -2159,6 +2159,8 @@ static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr)
return -EPERM;
if (copy_from_user(&t, useraddr, sizeof(t)))
return -EFAULT;
+ if (t.cmd != CHELSIO_SET_QSET_PARAMS)
+ return -EINVAL;
if (t.qset_idx >= SGE_QSETS)
return -EINVAL;
if (!in_range(t.intr_lat, 0, M_NEWTIMER) ||
@@ -2258,6 +2260,9 @@ static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr)
if (copy_from_user(&t, useraddr, sizeof(t)))
return -EFAULT;
+ if (t.cmd != CHELSIO_GET_QSET_PARAMS)
+ return -EINVAL;
+
/* Display qsets for all ports when offload enabled */
if (test_bit(OFFLOAD_DEVMAP_BIT, &adapter->open_device_map)) {
q1 = 0;
@@ -2303,6 +2308,8 @@ static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr)
return -EBUSY;
if (copy_from_user(&edata, useraddr, sizeof(edata)))
return -EFAULT;
+ if (edata.cmd != CHELSIO_SET_QSET_NUM)
+ return -EINVAL;
if (edata.val < 1 ||
(edata.val > 1 && !(adapter->flags & USING_MSIX)))
return -EINVAL;
@@ -2343,6 +2350,8 @@ static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr)
return -EPERM;
if (copy_from_user(&t, useraddr, sizeof(t)))
return -EFAULT;
+ if (t.cmd != CHELSIO_LOAD_FW)
+ return -EINVAL;
/* Check t.len sanity ? */
fw_data = memdup_user(useraddr + sizeof(t), t.len);
if (IS_ERR(fw_data))
@@ -2366,6 +2375,8 @@ static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr)
return -EBUSY;
if (copy_from_user(&m, useraddr, sizeof(m)))
return -EFAULT;
+ if (m.cmd != CHELSIO_SETMTUTAB)
+ return -EINVAL;
if (m.nmtus != NMTUS)
return -EINVAL;
if (m.mtus[0] < 81) /* accommodate SACK */
@@ -2407,6 +2418,8 @@ static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr)
return -EBUSY;
if (copy_from_user(&m, useraddr, sizeof(m)))
return -EFAULT;
+ if (m.cmd != CHELSIO_SET_PM)
+ return -EINVAL;
if (!is_power_of_2(m.rx_pg_sz) ||
!is_power_of_2(m.tx_pg_sz))
return -EINVAL; /* not power of 2 */
@@ -2440,6 +2453,8 @@ static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr)
return -EIO; /* need the memory controllers */
if (copy_from_user(&t, useraddr, sizeof(t)))
return -EFAULT;
+ if (t.cmd != CHELSIO_GET_MEM)
+ return -EINVAL;
if ((t.addr & 7) || (t.len & 7))
return -EINVAL;
if (t.mem_id == MEM_CM)
@@ -2492,6 +2507,8 @@ static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr)
return -EAGAIN;
if (copy_from_user(&t, useraddr, sizeof(t)))
return -EFAULT;
+ if (t.cmd != CHELSIO_SET_TRACE_FILTER)
+ return -EINVAL;
tp = (const struct trace_params *)&t.sip;
if (t.config_tx)
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next v6 00/23] WireGuard: Secure Network Tunnel
From: Jason A. Donenfeld @ 2018-10-05 13:46 UTC (permalink / raw)
To: Richard Weinberger
Cc: Eric Biggers, Ard Biesheuvel, Herbert Xu, LKML, Netdev,
Linux Crypto Mailing List, David Miller, Greg Kroah-Hartman
In-Reply-To: <CAFLxGvw154vyOziRKuFf5-XTa1NcQm5ZVmgUy3=F79k=Rw2dvA@mail.gmail.com>
On Fri, Oct 5, 2018 at 3:38 PM Richard Weinberger
<richard.weinberger@gmail.com> wrote:
> So we will have two competing crypo stacks in the kernel?
> Having a lightweight crypto API is a good thing but I really don't like the idea
> of having zinc parallel to the existing crypto stack.
No, as you've seen in this patchset, the dynamic dispatch crypto API
can trivially be done on top of Zinc. So each time we introduce a new
primitive to Zinc that's also in the dynamic dispatch API, we
reimplement the current crypto API in terms of Zinc. Check out the two
patches in this series that do this; it's quite clean and sleek.
> And I strongly vote that Herbert Xu shall remain the maintainer of the whole
> crypto system (including zinc!) in the kernel.
No, sorry, we intend to maintain the code we've written. But I am
amenable to taking a tree-route into upstream based on whatever makes
most sense with merge conflicts and such.
^ permalink raw reply
* [PATCH net 2/2] rxrpc: Fix the data_ready handler
From: David Howells @ 2018-10-05 13:43 UTC (permalink / raw)
To: netdev; +Cc: dhowells, linux-afs, linux-kernel
In-Reply-To: <153874697684.18195.15264114363303320691.stgit@warthog.procyon.org.uk>
Fix the rxrpc_data_ready() function to pick up all packets and to not miss
any. There are two problems:
(1) The sk_data_ready pointer on the UDP socket is set *after* it is
bound. This means that it's open for business before we're ready to
dequeue packets and there's a tiny window exists in which a packet can
sneak onto the receive queue, but we never know about it.
Fix this by setting the pointers on the socket prior to binding it.
(2) skb_recv_udp() will return an error (such as ENETUNREACH) if there was
an error on the transmission side, even though we set the
sk_error_report hook. Because rxrpc_data_ready() returns immediately
in such a case, it never actually removes its packet from the receive
queue.
Fix this by abstracting out the UDP dequeuing and checksumming into a
separate function that keeps hammering on skb_recv_udp() until it
returns -EAGAIN, passing the packets extracted to the remainder of the
function.
and two potential problems:
(3) It might be possible in some circumstances or in the future for
packets to be being added to the UDP receive queue whilst rxrpc is
running consuming them, so the data_ready() handler might get called
less often than once per packet.
Allow for this by fully draining the queue on each call as (2).
(4) If a packet fails the checksum check, the code currently returns after
discarding the packet without checking for more.
Allow for this by fully draining the queue on each call as (2).
Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both")
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Paolo Abeni <pabeni@redhat.com>
---
net/rxrpc/input.c | 68 ++++++++++++++++++++++++++--------------------
net/rxrpc/local_object.c | 11 ++++---
2 files changed, 44 insertions(+), 35 deletions(-)
diff --git a/net/rxrpc/input.c b/net/rxrpc/input.c
index c5af9955665b..c3114fa66c92 100644
--- a/net/rxrpc/input.c
+++ b/net/rxrpc/input.c
@@ -1121,7 +1121,7 @@ int rxrpc_extract_header(struct rxrpc_skb_priv *sp, struct sk_buff *skb)
* shut down and the local endpoint from going away, thus sk_user_data will not
* be cleared until this function returns.
*/
-void rxrpc_data_ready(struct sock *udp_sk)
+void rxrpc_input_packet(struct sock *udp_sk, struct sk_buff *skb)
{
struct rxrpc_connection *conn;
struct rxrpc_channel *chan;
@@ -1130,39 +1130,11 @@ void rxrpc_data_ready(struct sock *udp_sk)
struct rxrpc_local *local = udp_sk->sk_user_data;
struct rxrpc_peer *peer = NULL;
struct rxrpc_sock *rx = NULL;
- struct sk_buff *skb;
unsigned int channel;
- int ret, skew = 0;
+ int skew = 0;
_enter("%p", udp_sk);
- ASSERT(!irqs_disabled());
-
- skb = skb_recv_udp(udp_sk, 0, 1, &ret);
- if (!skb) {
- if (ret == -EAGAIN)
- return;
- _debug("UDP socket error %d", ret);
- return;
- }
-
- if (skb->tstamp == 0)
- skb->tstamp = ktime_get_real();
-
- rxrpc_new_skb(skb, rxrpc_skb_rx_received);
-
- _net("recv skb %p", skb);
-
- /* we'll probably need to checksum it (didn't call sock_recvmsg) */
- if (skb_checksum_complete(skb)) {
- rxrpc_free_skb(skb, rxrpc_skb_rx_freed);
- __UDP_INC_STATS(sock_net(udp_sk), UDP_MIB_INERRORS, 0);
- _leave(" [CSUM failed]");
- return;
- }
-
- __UDP_INC_STATS(sock_net(udp_sk), UDP_MIB_INDATAGRAMS, 0);
-
/* The UDP protocol already released all skb resources;
* we are free to add our own data there.
*/
@@ -1181,6 +1153,8 @@ void rxrpc_data_ready(struct sock *udp_sk)
}
}
+ if (skb->tstamp == 0)
+ skb->tstamp = ktime_get_real();
trace_rxrpc_rx_packet(sp);
switch (sp->hdr.type) {
@@ -1398,3 +1372,37 @@ void rxrpc_data_ready(struct sock *udp_sk)
rxrpc_reject_packet(local, skb);
_leave(" [badmsg]");
}
+
+void rxrpc_data_ready(struct sock *udp_sk)
+{
+ struct sk_buff *skb;
+ int ret;
+
+ for (;;) {
+ skb = skb_recv_udp(udp_sk, 0, 1, &ret);
+ if (!skb) {
+ if (ret == -EAGAIN)
+ return;
+
+ /* If there was a transmission failure, we get an error
+ * here that we need to ignore.
+ */
+ _debug("UDP socket error %d", ret);
+ continue;
+ }
+
+ rxrpc_new_skb(skb, rxrpc_skb_rx_received);
+
+ /* we'll probably need to checksum it (didn't call sock_recvmsg) */
+ if (skb_checksum_complete(skb)) {
+ rxrpc_free_skb(skb, rxrpc_skb_rx_freed);
+ __UDP_INC_STATS(sock_net(udp_sk), UDP_MIB_INERRORS, 0);
+ _debug("csum failed");
+ continue;
+ }
+
+ __UDP_INC_STATS(sock_net(udp_sk), UDP_MIB_INDATAGRAMS, 0);
+
+ rxrpc_input_packet(udp_sk, skb);
+ }
+}
diff --git a/net/rxrpc/local_object.c b/net/rxrpc/local_object.c
index 94d234e9c685..30862f44c9f1 100644
--- a/net/rxrpc/local_object.c
+++ b/net/rxrpc/local_object.c
@@ -122,6 +122,12 @@ static int rxrpc_open_socket(struct rxrpc_local *local, struct net *net)
return ret;
}
+ /* set the socket up */
+ sock = local->socket->sk;
+ sock->sk_user_data = local;
+ sock->sk_data_ready = rxrpc_data_ready;
+ sock->sk_error_report = rxrpc_error_report;
+
/* if a local address was supplied then bind it */
if (local->srx.transport_len > sizeof(sa_family_t)) {
_debug("bind");
@@ -191,11 +197,6 @@ static int rxrpc_open_socket(struct rxrpc_local *local, struct net *net)
BUG();
}
- /* set the socket up */
- sock = local->socket->sk;
- sock->sk_user_data = local;
- sock->sk_data_ready = rxrpc_data_ready;
- sock->sk_error_report = rxrpc_error_report;
_leave(" = 0");
return 0;
^ permalink raw reply related
* [PATCH net 1/2] rxrpc: Fix some missed refs to init_net
From: David Howells @ 2018-10-05 13:43 UTC (permalink / raw)
To: netdev; +Cc: dhowells, linux-afs, linux-kernel
In-Reply-To: <153874697684.18195.15264114363303320691.stgit@warthog.procyon.org.uk>
Fix some refs to init_net that should've been changed to the appropriate
network namespace.
Fixes: 2baec2c3f854 ("rxrpc: Support network namespacing")
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Paolo Abeni <pabeni@redhat.com>
---
net/rxrpc/ar-internal.h | 10 ++++++----
net/rxrpc/call_accept.c | 2 +-
net/rxrpc/call_object.c | 4 ++--
net/rxrpc/conn_client.c | 10 ++++++----
net/rxrpc/input.c | 4 ++--
net/rxrpc/peer_object.c | 28 +++++++++++++++++-----------
6 files changed, 34 insertions(+), 24 deletions(-)
diff --git a/net/rxrpc/ar-internal.h b/net/rxrpc/ar-internal.h
index ef9554131434..63c43b3a2096 100644
--- a/net/rxrpc/ar-internal.h
+++ b/net/rxrpc/ar-internal.h
@@ -891,8 +891,9 @@ extern unsigned long rxrpc_conn_idle_client_fast_expiry;
extern struct idr rxrpc_client_conn_ids;
void rxrpc_destroy_client_conn_ids(void);
-int rxrpc_connect_call(struct rxrpc_call *, struct rxrpc_conn_parameters *,
- struct sockaddr_rxrpc *, gfp_t);
+int rxrpc_connect_call(struct rxrpc_sock *, struct rxrpc_call *,
+ struct rxrpc_conn_parameters *, struct sockaddr_rxrpc *,
+ gfp_t);
void rxrpc_expose_client_call(struct rxrpc_call *);
void rxrpc_disconnect_client_call(struct rxrpc_call *);
void rxrpc_put_client_conn(struct rxrpc_connection *);
@@ -1045,10 +1046,11 @@ void rxrpc_peer_keepalive_worker(struct work_struct *);
*/
struct rxrpc_peer *rxrpc_lookup_peer_rcu(struct rxrpc_local *,
const struct sockaddr_rxrpc *);
-struct rxrpc_peer *rxrpc_lookup_peer(struct rxrpc_local *,
+struct rxrpc_peer *rxrpc_lookup_peer(struct rxrpc_sock *, struct rxrpc_local *,
struct sockaddr_rxrpc *, gfp_t);
struct rxrpc_peer *rxrpc_alloc_peer(struct rxrpc_local *, gfp_t);
-void rxrpc_new_incoming_peer(struct rxrpc_local *, struct rxrpc_peer *);
+void rxrpc_new_incoming_peer(struct rxrpc_sock *, struct rxrpc_local *,
+ struct rxrpc_peer *);
void rxrpc_destroy_all_peers(struct rxrpc_net *);
struct rxrpc_peer *rxrpc_get_peer(struct rxrpc_peer *);
struct rxrpc_peer *rxrpc_get_peer_maybe(struct rxrpc_peer *);
diff --git a/net/rxrpc/call_accept.c b/net/rxrpc/call_accept.c
index 9c7f26d06a52..f55f67894465 100644
--- a/net/rxrpc/call_accept.c
+++ b/net/rxrpc/call_accept.c
@@ -287,7 +287,7 @@ static struct rxrpc_call *rxrpc_alloc_incoming_call(struct rxrpc_sock *rx,
(peer_tail + 1) &
(RXRPC_BACKLOG_MAX - 1));
- rxrpc_new_incoming_peer(local, peer);
+ rxrpc_new_incoming_peer(rx, local, peer);
}
/* Now allocate and set up the connection */
diff --git a/net/rxrpc/call_object.c b/net/rxrpc/call_object.c
index 799f75b6900d..0ca2c2dfd196 100644
--- a/net/rxrpc/call_object.c
+++ b/net/rxrpc/call_object.c
@@ -287,7 +287,7 @@ struct rxrpc_call *rxrpc_new_client_call(struct rxrpc_sock *rx,
/* Set up or get a connection record and set the protocol parameters,
* including channel number and call ID.
*/
- ret = rxrpc_connect_call(call, cp, srx, gfp);
+ ret = rxrpc_connect_call(rx, call, cp, srx, gfp);
if (ret < 0)
goto error;
@@ -339,7 +339,7 @@ int rxrpc_retry_client_call(struct rxrpc_sock *rx,
/* Set up or get a connection record and set the protocol parameters,
* including channel number and call ID.
*/
- ret = rxrpc_connect_call(call, cp, srx, gfp);
+ ret = rxrpc_connect_call(rx, call, cp, srx, gfp);
if (ret < 0)
goto error;
diff --git a/net/rxrpc/conn_client.c b/net/rxrpc/conn_client.c
index 8acf74fe24c0..521189f4b666 100644
--- a/net/rxrpc/conn_client.c
+++ b/net/rxrpc/conn_client.c
@@ -276,7 +276,8 @@ static bool rxrpc_may_reuse_conn(struct rxrpc_connection *conn)
* If we return with a connection, the call will be on its waiting list. It's
* left to the caller to assign a channel and wake up the call.
*/
-static int rxrpc_get_client_conn(struct rxrpc_call *call,
+static int rxrpc_get_client_conn(struct rxrpc_sock *rx,
+ struct rxrpc_call *call,
struct rxrpc_conn_parameters *cp,
struct sockaddr_rxrpc *srx,
gfp_t gfp)
@@ -289,7 +290,7 @@ static int rxrpc_get_client_conn(struct rxrpc_call *call,
_enter("{%d,%lx},", call->debug_id, call->user_call_ID);
- cp->peer = rxrpc_lookup_peer(cp->local, srx, gfp);
+ cp->peer = rxrpc_lookup_peer(rx, cp->local, srx, gfp);
if (!cp->peer)
goto error;
@@ -683,7 +684,8 @@ static int rxrpc_wait_for_channel(struct rxrpc_call *call, gfp_t gfp)
* find a connection for a call
* - called in process context with IRQs enabled
*/
-int rxrpc_connect_call(struct rxrpc_call *call,
+int rxrpc_connect_call(struct rxrpc_sock *rx,
+ struct rxrpc_call *call,
struct rxrpc_conn_parameters *cp,
struct sockaddr_rxrpc *srx,
gfp_t gfp)
@@ -696,7 +698,7 @@ int rxrpc_connect_call(struct rxrpc_call *call,
rxrpc_discard_expired_client_conns(&rxnet->client_conn_reaper);
rxrpc_cull_active_client_conns(rxnet);
- ret = rxrpc_get_client_conn(call, cp, srx, gfp);
+ ret = rxrpc_get_client_conn(rx, call, cp, srx, gfp);
if (ret < 0)
goto out;
diff --git a/net/rxrpc/input.c b/net/rxrpc/input.c
index 800f5b8a1baa..c5af9955665b 100644
--- a/net/rxrpc/input.c
+++ b/net/rxrpc/input.c
@@ -1156,12 +1156,12 @@ void rxrpc_data_ready(struct sock *udp_sk)
/* we'll probably need to checksum it (didn't call sock_recvmsg) */
if (skb_checksum_complete(skb)) {
rxrpc_free_skb(skb, rxrpc_skb_rx_freed);
- __UDP_INC_STATS(&init_net, UDP_MIB_INERRORS, 0);
+ __UDP_INC_STATS(sock_net(udp_sk), UDP_MIB_INERRORS, 0);
_leave(" [CSUM failed]");
return;
}
- __UDP_INC_STATS(&init_net, UDP_MIB_INDATAGRAMS, 0);
+ __UDP_INC_STATS(sock_net(udp_sk), UDP_MIB_INDATAGRAMS, 0);
/* The UDP protocol already released all skb resources;
* we are free to add our own data there.
diff --git a/net/rxrpc/peer_object.c b/net/rxrpc/peer_object.c
index 01a9febfa367..2d39eaf19620 100644
--- a/net/rxrpc/peer_object.c
+++ b/net/rxrpc/peer_object.c
@@ -153,8 +153,10 @@ struct rxrpc_peer *rxrpc_lookup_peer_rcu(struct rxrpc_local *local,
* assess the MTU size for the network interface through which this peer is
* reached
*/
-static void rxrpc_assess_MTU_size(struct rxrpc_peer *peer)
+static void rxrpc_assess_MTU_size(struct rxrpc_sock *rx,
+ struct rxrpc_peer *peer)
{
+ struct net *net = sock_net(&rx->sk);
struct dst_entry *dst;
struct rtable *rt;
struct flowi fl;
@@ -169,7 +171,7 @@ static void rxrpc_assess_MTU_size(struct rxrpc_peer *peer)
switch (peer->srx.transport.family) {
case AF_INET:
rt = ip_route_output_ports(
- &init_net, fl4, NULL,
+ net, fl4, NULL,
peer->srx.transport.sin.sin_addr.s_addr, 0,
htons(7000), htons(7001), IPPROTO_UDP, 0, 0);
if (IS_ERR(rt)) {
@@ -188,7 +190,7 @@ static void rxrpc_assess_MTU_size(struct rxrpc_peer *peer)
sizeof(struct in6_addr));
fl6->fl6_dport = htons(7001);
fl6->fl6_sport = htons(7000);
- dst = ip6_route_output(&init_net, NULL, fl6);
+ dst = ip6_route_output(net, NULL, fl6);
if (dst->error) {
_leave(" [route err %d]", dst->error);
return;
@@ -240,10 +242,11 @@ struct rxrpc_peer *rxrpc_alloc_peer(struct rxrpc_local *local, gfp_t gfp)
/*
* Initialise peer record.
*/
-static void rxrpc_init_peer(struct rxrpc_peer *peer, unsigned long hash_key)
+static void rxrpc_init_peer(struct rxrpc_sock *rx, struct rxrpc_peer *peer,
+ unsigned long hash_key)
{
peer->hash_key = hash_key;
- rxrpc_assess_MTU_size(peer);
+ rxrpc_assess_MTU_size(rx, peer);
peer->mtu = peer->if_mtu;
peer->rtt_last_req = ktime_get_real();
@@ -275,7 +278,8 @@ static void rxrpc_init_peer(struct rxrpc_peer *peer, unsigned long hash_key)
/*
* Set up a new peer.
*/
-static struct rxrpc_peer *rxrpc_create_peer(struct rxrpc_local *local,
+static struct rxrpc_peer *rxrpc_create_peer(struct rxrpc_sock *rx,
+ struct rxrpc_local *local,
struct sockaddr_rxrpc *srx,
unsigned long hash_key,
gfp_t gfp)
@@ -287,7 +291,7 @@ static struct rxrpc_peer *rxrpc_create_peer(struct rxrpc_local *local,
peer = rxrpc_alloc_peer(local, gfp);
if (peer) {
memcpy(&peer->srx, srx, sizeof(*srx));
- rxrpc_init_peer(peer, hash_key);
+ rxrpc_init_peer(rx, peer, hash_key);
}
_leave(" = %p", peer);
@@ -299,14 +303,15 @@ static struct rxrpc_peer *rxrpc_create_peer(struct rxrpc_local *local,
* since we've already done a search in the list from the non-reentrant context
* (the data_ready handler) that is the only place we can add new peers.
*/
-void rxrpc_new_incoming_peer(struct rxrpc_local *local, struct rxrpc_peer *peer)
+void rxrpc_new_incoming_peer(struct rxrpc_sock *rx, struct rxrpc_local *local,
+ struct rxrpc_peer *peer)
{
struct rxrpc_net *rxnet = local->rxnet;
unsigned long hash_key;
hash_key = rxrpc_peer_hash_key(local, &peer->srx);
peer->local = local;
- rxrpc_init_peer(peer, hash_key);
+ rxrpc_init_peer(rx, peer, hash_key);
spin_lock(&rxnet->peer_hash_lock);
hash_add_rcu(rxnet->peer_hash, &peer->hash_link, hash_key);
@@ -317,7 +322,8 @@ void rxrpc_new_incoming_peer(struct rxrpc_local *local, struct rxrpc_peer *peer)
/*
* obtain a remote transport endpoint for the specified address
*/
-struct rxrpc_peer *rxrpc_lookup_peer(struct rxrpc_local *local,
+struct rxrpc_peer *rxrpc_lookup_peer(struct rxrpc_sock *rx,
+ struct rxrpc_local *local,
struct sockaddr_rxrpc *srx, gfp_t gfp)
{
struct rxrpc_peer *peer, *candidate;
@@ -337,7 +343,7 @@ struct rxrpc_peer *rxrpc_lookup_peer(struct rxrpc_local *local,
/* The peer is not yet present in hash - create a candidate
* for a new record and then redo the search.
*/
- candidate = rxrpc_create_peer(local, srx, hash_key, gfp);
+ candidate = rxrpc_create_peer(rx, local, srx, hash_key, gfp);
if (!candidate) {
_leave(" = NULL [nomem]");
return NULL;
^ permalink raw reply related
* [PATCH net 0/2] rxrpc: Fixes
From: David Howells @ 2018-10-05 13:42 UTC (permalink / raw)
To: netdev; +Cc: dhowells, linux-afs, linux-kernel
Here are two fixes for AF_RXRPC:
(1) Fix some places that are doing things in the wrong net namespace.
(2) Fix the reception of UDP packets in three ways:
(a) Close the window between binding the socket and setting the
data_ready hook in which packets can come in and get lodged in the
receive queue without data_ready seeing them.
(b) Make sure the UDP receive queue is drained before returning from
the data_ready hook.
(c) Ignore Tx errors returned by skb_recv_udp().
The patches are tagged here:
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
rxrpc-fixes-20181005
and can also be found on the following branch:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-fixes
David
---
David Howells (2):
rxrpc: Fix some missed refs to init_net
rxrpc: Fix the data_ready handler
net/rxrpc/ar-internal.h | 10 ++++---
net/rxrpc/call_accept.c | 2 +
net/rxrpc/call_object.c | 4 +--
net/rxrpc/conn_client.c | 10 ++++---
net/rxrpc/input.c | 68 ++++++++++++++++++++++++++--------------------
net/rxrpc/local_object.c | 11 ++++---
net/rxrpc/peer_object.c | 28 ++++++++++++-------
7 files changed, 76 insertions(+), 57 deletions(-)
^ permalink raw reply
* Re: [PATCH] net: wireless: iwlegacy: Fix possible data races in il4965_send_rxon_assoc()
From: Jia-Ju Bai @ 2018-10-05 13:42 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: kvalo, davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <20181005075403.GC1931@redhat.com>
On 2018/10/5 15:54, Stanislaw Gruszka wrote:
> On Thu, Oct 04, 2018 at 04:52:19PM +0800, Jia-Ju Bai wrote:
>> On 2018/10/4 15:59, Stanislaw Gruszka wrote:
>>> On Wed, Oct 03, 2018 at 10:07:45PM +0800, Jia-Ju Bai wrote:
>>>> These possible races are detected by a runtime testing.
>>>> To fix these races, the mutex lock is used in il4965_send_rxon_assoc()
>>>> to protect the data.
>>> Really ? I'm surprised by that, see below.
>> My runtime testing shows that il4965_send_rxon_assoc() and
>> il4965_configure_filter() are concurrently executed.
>> But after seeing your reply, I need to carefully check whether my
>> runtime testing is right, because I think you are right.
>> In fact, I only monitored the iwl4965 driver, but did not monitor
>> the iwlegacy driver, so I will do the testing again with monitoring
>> the lwlegacy driver.
> <snip>
>>> So I wonder how this patch did not cause the deadlock ?
>> Oh, sorry, anyway, my patch will cause double locks...
> So how those runtime test were performend such you didn't
> notice this ?
I write a tool to perform runtime testing.
This tool records the lock status during driver execution.
Some calls to mutex_lock() are in common.c that I did not handle, so the
corresponding lock status was not recorded by my tool, causing this
false positive.
Now I have handled common.c, and this false positive is not reported any
more.
Actually, I get several new reports.
I will send you these reports to you later, and hope you can have a
look, thanks in advance :)
>
>>> Anyway what can be done is adding:
>>>
>>> lockdep_assert_held(&il->mutex);
>>>
>>> il4965_commit_rxon() to check if we hold the mutex.
>> I agree.
> Care to post a patch ?
Sure :)
Best wishes,
Jia-Ju Bai
^ permalink raw reply
* Re: [PATCH net-next v6 00/23] WireGuard: Secure Network Tunnel
From: Richard Weinberger @ 2018-10-05 13:37 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: ebiggers, Ard Biesheuvel, Herbert Xu, LKML, netdev, linux-crypto,
David S. Miller, Greg KH
In-Reply-To: <CAHmME9ogY=v2Le85+_=-m++RwAzwiUmKyNzx6N2y9Ht-J7xBcQ@mail.gmail.com>
On Fri, Oct 5, 2018 at 3:14 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> On Wed, Oct 3, 2018 at 8:49 AM Eric Biggers <ebiggers@kernel.org> wrote:
> > It's not really about the name, though. It's actually about the whole way of
> > thinking about the submission. Is it a new special library with its own things
> > going on, or is it just some crypto helper functions? It's really just the
> > latter, but you've been presenting it as the former
>
> No, it really is its own thing with important differences from the
> present crypto api. Zinc's focus is on simplicity and clarity. To the
> extent that we're at all tangled with the current crypto api, the goal
> is to untangle as much as possible. It intends to be a small and
> lightweight set of routines, whose relationships are obvious, and with
> this direct and to the point organization, as well as work with the larger
> cryptography community and with academia to invite collaboration. With
> this comes a different way of maintaining it, with higher standards
> and a preference for different implementations than the current
> situation. With Zinc, you have an obvious series of C function calls
> composing the whole thing, without complicated indirection. It's
> something that could be trivially lifted out into a userspace library,
> and used broadly, for example -- something I'll probably do at some
> point. That's a bit of a design change to the current crypto api, and
> sprinkling some direct function calls within the current crypto api's
> complicated enterprise situation would only kick the can further down
> the road, as much complexity would still remain. The goal is to move
> away from behemoth enterprise APIs, and large and complex codebases to
> a simple and direct way of doing things. This desire to untangle, to
> start from a simpler base, and to generally do things differently
> means it will go into lib/zinc/ and include/zinc/ and have different
> maintainers.
So we will have two competing crypo stacks in the kernel?
Having a lightweight crypto API is a good thing but I really don't like the idea
of having zinc parallel to the existing crypto stack.
And I strongly vote that Herbert Xu shall remain the maintainer of the whole
crypto system (including zinc!) in the kernel.
--
Thanks,
//richard
^ permalink raw reply
* Re: [PATCH] SUNRPC: use cmpxchg64() in gss_seq_send64_fetch_and_inc()
From: Trond Myklebust @ 2018-10-05 13:36 UTC (permalink / raw)
To: arnd@arndb.de
Cc: linux-kernel@vger.kernel.org, jlayton@kernel.org,
bfields@fieldses.org, linux-nfs@vger.kernel.org,
james@ettle.org.uk, anna.schumaker@netapp.com,
netdev@vger.kernel.org, davem@davemloft.net,
stephen@networkplumber.org
In-Reply-To: <20181002205809.2300654-1-arnd@arndb.de>
On Tue, 2018-10-02 at 22:57 +0200, Arnd Bergmann wrote:
> The newly introduced gss_seq_send64_fetch_and_inc() fails to build on
> 32-bit architectures:
>
> net/sunrpc/auth_gss/gss_krb5_seal.c:144:14: note: in expansion of
> macro 'cmpxchg'
> seq_send = cmpxchg(&ctx->seq_send64, old, old + 1);
> ^~~~~~~
> arch/x86/include/asm/cmpxchg.h:128:3: error: call to
> '__cmpxchg_wrong_size' declared with attribute error: Bad argument
> size for cmpxchg
> __cmpxchg_wrong_size(); \
>
> As the message tells us, cmpxchg() cannot be used on 64-bit
> arguments,
> that's what cmpxchg64() does.
>
> Fixes: 571ed1fd2390 ("SUNRPC: Replace krb5_seq_lock with a lockless
> scheme")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> net/sunrpc/auth_gss/gss_krb5_seal.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/sunrpc/auth_gss/gss_krb5_seal.c
> b/net/sunrpc/auth_gss/gss_krb5_seal.c
> index 92594681d619..5775b9805bdc 100644
> --- a/net/sunrpc/auth_gss/gss_krb5_seal.c
> +++ b/net/sunrpc/auth_gss/gss_krb5_seal.c
> @@ -141,7 +141,7 @@ gss_seq_send64_fetch_and_inc(struct krb5_ctx
> *ctx)
>
> do {
> old = seq_send;
> - seq_send = cmpxchg(&ctx->seq_send64, old, old + 1);
> + seq_send = cmpxchg64(&ctx->seq_send64, old, old + 1);
> } while (old != seq_send);
> return seq_send;
> }
Thanks Arndt! Applied.
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com
^ permalink raw reply
* [PATCH] gigaset: asyncdata: mark expected switch fall-throughs
From: Gustavo A. R. Silva @ 2018-10-05 13:29 UTC (permalink / raw)
To: Paul Bolle, Karsten Keil
Cc: gigaset307x-common, netdev, linux-kernel, Gustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Notice that in this particular case, I replaced the
" --v-- fall through --v-- " comment with a proper
"fall through", which is what GCC is expecting to find.
Addresses-Coverity-ID: 1364476 ("Missing break in switch")
Addresses-Coverity-ID: 1364477 ("Missing break in switch")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/isdn/gigaset/asyncdata.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/isdn/gigaset/asyncdata.c b/drivers/isdn/gigaset/asyncdata.c
index bc20855..c0cbee0 100644
--- a/drivers/isdn/gigaset/asyncdata.c
+++ b/drivers/isdn/gigaset/asyncdata.c
@@ -65,7 +65,7 @@ static unsigned cmd_loop(unsigned numbytes, struct inbuf_t *inbuf)
cs->respdata[0] = 0;
break;
}
- /* --v-- fall through --v-- */
+ /* fall through */
case '\r':
/* end of message line, pass to response handler */
if (cbytes >= MAX_RESP_SIZE) {
@@ -100,7 +100,7 @@ static unsigned cmd_loop(unsigned numbytes, struct inbuf_t *inbuf)
goto exit;
}
/* quoted or not in DLE mode: treat as regular data */
- /* --v-- fall through --v-- */
+ /* fall through */
default:
/* append to line buffer if possible */
if (cbytes < MAX_RESP_SIZE)
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next v6 00/23] WireGuard: Secure Network Tunnel
From: Jason A. Donenfeld @ 2018-10-05 13:13 UTC (permalink / raw)
To: Eric Biggers
Cc: Ard Biesheuvel, Herbert Xu, LKML, Netdev,
Linux Crypto Mailing List, David Miller, Greg Kroah-Hartman
In-Reply-To: <20181003064951.GC745@sol.localdomain>
Hi Eric,
On Wed, Oct 3, 2018 at 8:49 AM Eric Biggers <ebiggers@kernel.org> wrote:
> It's not really about the name, though. It's actually about the whole way of
> thinking about the submission. Is it a new special library with its own things
> going on, or is it just some crypto helper functions? It's really just the
> latter, but you've been presenting it as the former
No, it really is its own thing with important differences from the
present crypto api. Zinc's focus is on simplicity and clarity. To the
extent that we're at all tangled with the current crypto api, the goal
is to untangle as much as possible. It intends to be a small and
lightweight set of routines, whose relationships are obvious, and with
this direct and to the point organization, as well as work with the larger
cryptography community and with academia to invite collaboration. With
this comes a different way of maintaining it, with higher standards
and a preference for different implementations than the current
situation. With Zinc, you have an obvious series of C function calls
composing the whole thing, without complicated indirection. It's
something that could be trivially lifted out into a userspace library,
and used broadly, for example -- something I'll probably do at some
point. That's a bit of a design change to the current crypto api, and
sprinkling some direct function calls within the current crypto api's
complicated enterprise situation would only kick the can further down
the road, as much complexity would still remain. The goal is to move
away from behemoth enterprise APIs, and large and complex codebases to
a simple and direct way of doing things. This desire to untangle, to
start from a simpler base, and to generally do things differently
means it will go into lib/zinc/ and include/zinc/ and have different
maintainers.
Jason
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: emit audit messages upon successful prog load and unload
From: Jiri Olsa @ 2018-10-05 6:14 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Jesper Dangaard Brouer, Daniel Borkmann, ast, netdev, Jiri Olsa,
acme
In-Reply-To: <20181004221013.o3c5junwfyaasuxo@ast-mbp.dhcp.thefacebook.com>
On Thu, Oct 04, 2018 at 03:10:15PM -0700, Alexei Starovoitov wrote:
> On Thu, Oct 04, 2018 at 10:22:31PM +0200, Jesper Dangaard Brouer wrote:
> > On Thu, 4 Oct 2018 21:41:17 +0200 Daniel Borkmann <daniel@iogearbox.net> wrote:
> >
> > > On 10/04/2018 08:39 PM, Jesper Dangaard Brouer wrote:
> > > > On Thu, 4 Oct 2018 10:11:43 -0700 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> > > >> On Thu, Oct 04, 2018 at 03:50:38PM +0200, Daniel Borkmann wrote:
> > [...]
> > > >>
> > > >> If the purpose of the patch is to give user space visibility into
> > > >> bpf prog load/unload as a notification, then I completely agree that
> > > >> some notification mechanism is necessary.
> > >
> > > Yeah, I did only regard it as only that, nothing more. Some means
> > > of timeline and notification that can be kept in a record in user
> > > space and later retrieved e.g. for introspection on what has been
> > > loaded.
> > >
> > > >> I've started working on such mechanism via perf ring buffer which is
> > > >> the fastest mechanism we have in the kernel so far.
> > > >> See long discussion here: https://patchwork.ozlabs.org/patch/971970/
cool, could you please CC me if there's another version
of that patchset?
> > >
> > > That one is definitely needed in any case to resolve the kallsyms
> > > limitations, and it does have overlap in that in either case we
> > > want to look at past BPF programs that have been unloaded in the
> > > meantime, so I don't have a strong preference either way, and the
> > > former is needed in any case. Though thought was that audit might
> > > be an option for those not running profiling daemons 24/7, but
> > > presumably bpftool could be extended to record these events as
> > > well if we don't want to reuse audit infra.
> >
> > Yes, exactly, I don't want to run a profiling daemon 24/7 to record
> > these events. I do acknowledge that this perf event is relevant,
> > especially for catching the kernel symbols (I need that myself), but it
> > does not cover my use-case.
> >
> > My use-case is to 24/7 collect and keep records in userspace, and have a
> > timeline of these notifications, for later retrieval. The idea is that
> > our support engineers can look at these records when troubleshooting
> > the system. And the plan is also to collect these records as part of
> > our sosreport tool, which is part of the support case.
>
> I don't think you're implying that prog load/unload should be spamming dmesg
> and auditd not even running...
I think the problem Jesper implied is that in order to collect
those logs you'll need perf tool running all the time.. which
it's not equipped for yet
jirka
> Also auditd has to be changed to support retrieving prog related info (like license)
> via sys_bpf system call when it sees prog_id.
> Since it has to change it can just as easily use perf ring buffer
> to receive notifications.
> So we solve notification problem once and all user space tools can use it.
>
^ permalink raw reply
* Re: [PATCH] net/packet: fix packet drop as of virtio gso
From: David Miller @ 2018-10-05 5:23 UTC (permalink / raw)
To: jianfeng.tan; +Cc: netdev, jasowang, mst
In-Reply-To: <20180929154127.20867-1-jianfeng.tan@linux.alibaba.com>
From: Jianfeng Tan <jianfeng.tan@linux.alibaba.com>
Date: Sat, 29 Sep 2018 15:41:27 +0000
> When we use raw socket as the vhost backend, a packet from virito with
> gso offloading information, cannot be sent out in later validaton at
> xmit path, as we did not set correct skb->protocol which is further used
> for looking up the gso function.
>
> To fix this, we set this field according to virito hdr information.
>
> Fixes: e858fae2b0b8f4 ("virtio_net: use common code for virtio_net_hdr and skb GSO conversion")
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Jianfeng Tan <jianfeng.tan@linux.alibaba.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH v2 0/5] Introducing ixgbe AF_XDP ZC support
From: Björn Töpel @ 2018-10-05 4:59 UTC (permalink / raw)
To: Jesper Dangaard Brouer, Björn Töpel
Cc: jeffrey.t.kirsher, intel-wired-lan, magnus.karlsson,
magnus.karlsson, ast, daniel, netdev, u9012063, tuc,
jakub.kicinski
In-Reply-To: <20181004231848.33efd81f@redhat.com>
On 2018-10-04 23:18, Jesper Dangaard Brouer wrote:
> I see similar performance numbers, but my system can crash with 'txonly'.
Thanks for finding this, Jesper!
Can you give me your "lspci -vvv" dump of your NIC, so I know what ixgbe
flavor you've got?
I'll dig into it right away.
Björn
^ permalink raw reply
* Re: [PATCH] openvswitch: load NAT helper
From: David Miller @ 2018-10-05 4:55 UTC (permalink / raw)
To: fbl; +Cc: netfilter-devel, netdev, dev, pshelar
In-Reply-To: <20180928175128.13126-1-fbl@redhat.com>
From: Flavio Leitner <fbl@redhat.com>
Date: Fri, 28 Sep 2018 14:51:28 -0300
> Load the respective NAT helper module if the flow uses it.
>
> Signed-off-by: Flavio Leitner <fbl@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/5] net: Consolidate metrics handling for ipv4 and ipv6
From: David Miller @ 2018-10-05 4:55 UTC (permalink / raw)
To: dsahern; +Cc: netdev, weiwan, sd, xiyou.wangcong, dsahern
In-Reply-To: <20181005030755.31217-1-dsahern@kernel.org>
From: David Ahern <dsahern@kernel.org>
Date: Thu, 4 Oct 2018 20:07:50 -0700
> From: David Ahern <dsahern@gmail.com>
>
> As part of the IPv6 fib info refactoring, the intent was to make metrics
> handling for ipv6 identical to ipv4. One oversight in ip6_dst_destroy
> led to confusion and a couple of incomplete attempts at finding and
> fixing the resulting memory leak which was ultimately resolved by
> ce7ea4af0838 ("ipv6: fix memory leak on dst->_metrics").
>
> Refactor metrics hanlding make the code really identical for v4 and v6,
> and add a few test cases.
Looks nice, series applied, thanks David.
^ permalink raw reply
* RE: [PATCH 2/2] netdev/phy: add MDIO bus multiplexer driven by a regmap
From: Pankaj Bansal @ 2018-10-05 4:31 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Florian Fainelli, netdev@vger.kernel.org, Alexandru Marginean
In-Reply-To: <20181005035142.GC7715@lunn.ch>
Hi Andrew
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Friday, October 5, 2018 9:22 AM
> To: Pankaj Bansal <pankaj.bansal@nxp.com>
> Cc: Florian Fainelli <f.fainelli@gmail.com>; netdev@vger.kernel.org;
> Alexandru Marginean <alexandru.marginean@nxp.com>
> Subject: Re: [PATCH 2/2] netdev/phy: add MDIO bus multiplexer driven by a
> regmap
>
> On Fri, Oct 05, 2018 at 01:59:26PM +0530, Pankaj Bansal wrote:
> > Add support for an MDIO bus multiplexer controlled by a regmap device,
> > like an FPGA.
> >
> > Tested on a NXP LX2160AQDS board which uses the "QIXIS" FPGA
> attached
> > to the i2c bus.
> >
> > Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
> > ---
> > drivers/net/phy/Kconfig | 13 ++
> > drivers/net/phy/Makefile | 1 +
> > drivers/net/phy/mdio-mux-regmap.c | 177
> ++++++++++++++++++++++++++++
> > 3 files changed, 191 insertions(+)
> >
> > diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig index
> > 82070792edbb..bb894ede7464 100644
> > --- a/drivers/net/phy/Kconfig
> > +++ b/drivers/net/phy/Kconfig
> > @@ -87,6 +87,19 @@ config MDIO_BUS_MUX_MMIOREG
> >
> > Currently, only 8/16/32 bits registers are supported.
> >
> > +config MDIO_BUS_MUX_REGMAP
> > + tristate "REGMAP controlled MDIO bus multiplexers"
> > + depends on OF_MDIO && HAS_IOMEM
>
> Hi Pankaj
>
> Doesn't it also depend on REGMAP?
I will add
>
> > + select MDIO_BUS_MUX
> > + help
> > + This module provides a driver for MDIO bus multiplexers that
> > + are controlled via a regmap, like an FPGA.
> > + The multiplexer connects one of several child MDIO busses to a
> > + parent bus. Child bus selection is under the control of one of
> > + the FPGA's registers.
> > +
> > + Currently, only upto 32 bits registers are supported.
> > +
> > config MDIO_CAVIUM
> > tristate
> >
> > diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile index
> > 5805c0b7d60e..33053f9f320d 100644
> > --- a/drivers/net/phy/Makefile
> > +++ b/drivers/net/phy/Makefile
> > @@ -29,6 +29,7 @@ obj-$(CONFIG_MDIO_BUS_MUX) += mdio-
> mux.o
> > obj-$(CONFIG_MDIO_BUS_MUX_BCM_IPROC) += mdio-mux-bcm-
> iproc.o
> > obj-$(CONFIG_MDIO_BUS_MUX_GPIO) += mdio-mux-gpio.o
> > obj-$(CONFIG_MDIO_BUS_MUX_MMIOREG) += mdio-mux-mmioreg.o
> > +obj-$(CONFIG_MDIO_BUS_MUX_REGMAP) += mdio-mux-regmap.o
> > obj-$(CONFIG_MDIO_CAVIUM) += mdio-cavium.o
> > obj-$(CONFIG_MDIO_GPIO) += mdio-gpio.o
> > obj-$(CONFIG_MDIO_HISI_FEMAC) += mdio-hisi-femac.o
> > diff --git a/drivers/net/phy/mdio-mux-regmap.c
> > b/drivers/net/phy/mdio-mux-regmap.c
> > new file mode 100644
> > index 000000000000..b0882273fd47
> > --- /dev/null
> > +++ b/drivers/net/phy/mdio-mux-regmap.c
> > @@ -0,0 +1,177 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +
> > +/* Simple regmap based MDIO MUX driver
> > + *
> > + * Copyright 2018 NXP
> > + *
> > + * Based on mdio-mux-mmioreg.c by Timur Tabi
> > + *
> > + * Author:
> > + * Pankaj Bansal <pankaj.bansal@nxp.com>
> > + */
> > +
> > +#include <linux/platform_device.h>
> > +#include <linux/device.h>
> > +#include <linux/of_mdio.h>
> > +#include <linux/module.h>
> > +#include <linux/phy.h>
> > +#include <linux/mdio-mux.h>
> > +#include <linux/regmap.h>
> > +
> > +struct mdio_mux_regmap_state {
> > + void *mux_handle;
> > + struct regmap *regmap;
> > + u32 mux_reg;
> > + u32 mask;
> > +};
> > +
> > +/* MDIO multiplexing switch function
> > + *
> > + * This function is called by the mdio-mux layer when it thinks the
> > +mdio bus
> > + * multiplexer needs to switch.
> > + *
> > + * 'current_child' is the current value of the mux register (masked
> > +via
> > + * s->mask).
> > + *
> > + * 'desired_child' is the value of the 'reg' property of the target
> > +child MDIO
> > + * node.
> > + *
> > + * The first time this function is called, current_child == -1.
> > + *
> > + * If current_child == desired_child, then the mux is already set to
> > +the
> > + * correct bus.
> > + */
> > +static int mdio_mux_regmap_switch_fn(int current_child, int
> desired_child,
> > + void *data)
> > +{
> > + struct mdio_mux_regmap_state *s = data;
> > + bool change;
> > + int ret = 0;
> > +
>
> No need to initialise ret.
Ok
>
> > + ret = regmap_update_bits_check(s->regmap,
> > + s->mux_reg,
> > + s->mask,
> > + desired_child,
> > + &change);
>
> When getting the mask from DT, you use be32_to_cpup().
> When testing the reg value against the mask, you use be32_to_cpup().
> Here you do not use be32_to_cpup()?
Can you please tell me for which variable you mean I should use be32_to_cpup?
I use be32_to_cpup when reading device tree entries.
After being read, their values are stored in structure. After that no need to do be32_to_cpup
>
> > +
> > + if (ret)
> > + goto out;
>
> Just do the return here.
Ok
>
> > + if (change)
> > + pr_debug("%s %d -> %d\n", __func__, current_child,
> > + desired_child);
> > +
> > +out:
> > + return ret;
> > +}
> > +
> > +static int mdio_mux_regmap_probe(struct platform_device *pdev) {
> > + struct device_node *np2, *np = pdev->dev.of_node;
> > + struct mdio_mux_regmap_state *s;
> > + const __be32 *iprop;
> > + int len, ret;
> > + u32 val;
> > +
> > + dev_dbg(&pdev->dev, "probing node %pOF\n", np);
> > +
> > + s = devm_kzalloc(&pdev->dev, sizeof(*s), GFP_KERNEL);
> > + if (!s)
> > + return -ENOMEM;
> > +
> > + s->regmap = dev_get_regmap(pdev->dev.parent, NULL);
> > + if (IS_ERR(s->regmap)) {
> > + dev_err(&pdev->dev, "Failed to get parent regmap\n");
> > + ret = PTR_ERR(s->regmap);
> > + return ret;
>
> return PTR_ERR(s->regmap);
Ok
>
> > + }
> > +
> > + iprop = of_get_property(np, "reg", &len);
> > + if (!iprop || len != sizeof(u32)) {
> > + dev_err(&pdev->dev, "missing or invalid reg property\n");
> > + return -ENODEV;
> > + }
> > + s->mux_reg = (u32)be32_to_cpup(iprop);
> > +
> > + /* Test Register read write */
> > + ret = regmap_read(s->regmap, s->mux_reg, &val);
> > + if (ret) {
> > + dev_err(&pdev->dev, "error while reading reg\n");
> > + return ret;
> > + }
> > +
> > + ret = regmap_write(s->regmap, s->mux_reg, val);
> > + if (ret) {
> > + dev_err(&pdev->dev, "error while writing reg\n");
> > + return ret;
> > + }
> > +
> > + iprop = of_get_property(np, "mux-mask", &len);
> > + if (!iprop || len != sizeof(u32)) {
> > + dev_err(&pdev->dev, "missing or invalid mux-mask
> property\n");
> > + return -ENODEV;
> > + }
> > + s->mask = (uint32_t)be32_to_cpup(iprop);
>
> Is this cast needed?
I will remove the typecasts.
>
> > +
> > + /* Verify that the 'reg' property of each child MDIO bus does not
> > + * set any bits outside of the 'mask'.
> > + */
> > + for_each_available_child_of_node(np, np2) {
> > + iprop = of_get_property(np2, "reg", &len);
> > + if (!iprop || len != sizeof(u32)) {
> > + dev_err(&pdev->dev, "mdio-mux child node %pOF is
> missing a 'reg' property\n", np2);
> > + of_node_put(np2);
> > + return -ENODEV;
> > + }
> > + if (be32_to_cpup(iprop) & ~s->mask) {
> > + dev_err(&pdev->dev, "mdio-mux child node %pOF
> has a 'reg' value with unmasked bits\n", np2);
> > + of_node_put(np2);
> > + return -ENODEV;
> > + }
> > + }
> > +
> > + ret = mdio_mux_init(&pdev->dev, pdev->dev.of_node,
> > + mdio_mux_regmap_switch_fn,
> > + &s->mux_handle, s, NULL);
> > + if (ret) {
> > + if (ret != -EPROBE_DEFER)
> > + dev_err(&pdev->dev,
> > + "failed to register mdio-mux bus %pOF\n",
> np);
> > + return ret;
> > + }
> > +
> > + pdev->dev.platform_data = s;
> > + return 0;
> > +}
> > +
> > +static int mdio_mux_regmap_remove(struct platform_device *pdev) {
> > + struct mdio_mux_regmap_state *s = dev_get_platdata(&pdev-
> >dev);
> > +
> > + mdio_mux_uninit(s->mux_handle);
> > +
> > + return 0;
> > +}
> > +
> > +static const struct of_device_id mdio_mux_regmap_match[] = {
> > + {
> > + .compatible = "mdio-mux-regmap",
> > + },
> > + {},
> > +};
> > +MODULE_DEVICE_TABLE(of, mdio_mux_regmap_match);
> > +
> > +static struct platform_driver mdio_mux_regmap_driver = {
> > + .driver = {
> > + .name = "mdio-mux-regmap",
> > + .of_match_table = mdio_mux_regmap_match,
> > + },
> > + .probe = mdio_mux_regmap_probe,
> > + .remove = mdio_mux_regmap_remove,
> > +};
> > +
> > +module_platform_driver(mdio_mux_regmap_driver);
> > +
> > +MODULE_AUTHOR("Pankaj Bansal <pankaj.bansal@nxp.com>");
> > +MODULE_DESCRIPTION("I2c device MDIO MUX driver");
>
> I2C should be replaced by regmap.
Nice catch. I will replace it.
>
> Andrew
^ permalink raw reply
* Re: [PATCH 2/2] can: tcan4x5x: Add tcan4x5x driver to the kernel
From: Dan Murphy @ 2018-10-05 11:45 UTC (permalink / raw)
To: Wolfgang Grandegger, mkl, davem
Cc: linux-can, netdev, linux-kernel, Mario.Huettel
In-Reply-To: <6f055cd9-9452-0b4c-2df2-3d0cc06f9e68@grandegger.com>
Wolfgang
On 10/05/2018 12:56 AM, Wolfgang Grandegger wrote:
> Hello Dan,
>
> Am 04.10.2018 um 22:26 schrieb Dan Murphy:
>> Wolfgang
>>
>> On 09/26/2018 12:54 PM, Wolfgang Grandegger wrote:
>>> Hello,
>>>
>>> I wonder why you do not extend the existing MCAN driver by implementing
>>> an interface to access the hardware. Would that be feasible?
>>>
>>
>> I have created a m_can_core code base that can be used by other hardware that
>> have special needs.
>>
>> So I have created the m_can_core, m_can and the tcan4x5x drivers.
>
> Great, I still think it's a good idea to have just one "m_can" driver.
The m_can and tcan4x5x provide the device level implementations. The m_can_core
deals specifically with handling of the m_can IP and protocol.
>
>> I can RFC the code to see if this is what is expected.
>> It is not 100% working but it is close enough for a directional call.
>
> That would be nice! Most of the SPI accesses are pure register accesses.
> A few read/write more bytes at a time (for data, etc.) but that could be
> handled by appropriate interface functions. One general problem is that
> SPI accesses are not possible from interrupt context requiring threads
> or work queues. Also NAPI is usually not used.
>
> Other opinions?
agreed. Is there any issue with moving the request_irq to a threaded_irq?
Not sure how that would affect the timing.
>
> Wolfgang.
>
> PS: I have added Mario to the CC. Maybe he could test a common driver on
> his M_CAN hardware.
>
I found that our am5/dra76 EVM also uses this IP stack. So I am working with
our experts there to test and review the code as well.
Dan
--
------------------
Dan Murphy
^ permalink raw reply
* Re: [PATCH v3] net/ncsi: Add NCSI OEM command support
From: Samuel Mendoza-Jonas @ 2018-10-05 4:47 UTC (permalink / raw)
To: Vijay Khemka, Justin . Lee1 @ Dell . com, joel @ jms . id . au,
linux-aspeed @ lists . ozlabs . org,
openbmc @ lists . ozlabs . org, Sai Dasari,
netdev @ vger . kernel . org, christian @ cmd . nu
In-Reply-To: <20181003233222.3909359-1-vijaykhemka@fb.com>
On Wed, 2018-10-03 at 16:32 -0700, Vijay Khemka wrote:
> This patch adds OEM commands and response handling. It also defines OEM
> command and response structure as per NCSI specification along with its
> handlers.
>
> ncsi_cmd_handler_oem: This is a generic command request handler for OEM
> commands
> ncsi_rsp_handler_oem: This is a generic response handler for OEM commands
>
> Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
Reviewed-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
Technically this patch should also be marked [PATCH net-next] to target
David's next tree.
> ---
> net/ncsi/internal.h | 5 +++++
> net/ncsi/ncsi-cmd.c | 30 +++++++++++++++++++++++++++---
> net/ncsi/ncsi-pkt.h | 14 ++++++++++++++
> net/ncsi/ncsi-rsp.c | 43 ++++++++++++++++++++++++++++++++++++++++++-
> 4 files changed, 88 insertions(+), 4 deletions(-)
>
> diff --git a/net/ncsi/internal.h b/net/ncsi/internal.h
> index 8055e3965cef..3d0a33b874f5 100644
> --- a/net/ncsi/internal.h
> +++ b/net/ncsi/internal.h
> @@ -68,6 +68,10 @@ enum {
> NCSI_MODE_MAX
> };
>
> +/* OEM Vendor Manufacture ID */
> +#define NCSI_OEM_MFR_MLX_ID 0x8119
> +#define NCSI_OEM_MFR_BCM_ID 0x113d
> +
> struct ncsi_channel_version {
> u32 version; /* Supported BCD encoded NCSI version */
> u32 alpha2; /* Supported BCD encoded NCSI version */
> @@ -305,6 +309,7 @@ struct ncsi_cmd_arg {
> unsigned short words[8];
> unsigned int dwords[4];
> };
> + unsigned char *data; /* NCSI OEM data */
> };
>
> extern struct list_head ncsi_dev_list;
> diff --git a/net/ncsi/ncsi-cmd.c b/net/ncsi/ncsi-cmd.c
> index 7567ca63aae2..82b7d9201db8 100644
> --- a/net/ncsi/ncsi-cmd.c
> +++ b/net/ncsi/ncsi-cmd.c
> @@ -211,6 +211,25 @@ static int ncsi_cmd_handler_snfc(struct sk_buff *skb,
> return 0;
> }
>
> +static int ncsi_cmd_handler_oem(struct sk_buff *skb,
> + struct ncsi_cmd_arg *nca)
> +{
> + struct ncsi_cmd_oem_pkt *cmd;
> + unsigned int len;
> +
> + len = sizeof(struct ncsi_cmd_pkt_hdr) + 4;
> + if (nca->payload < 26)
> + len += 26;
> + else
> + len += nca->payload;
> +
> + cmd = skb_put_zero(skb, len);
> + memcpy(&cmd->mfr_id, nca->data, nca->payload);
> + ncsi_cmd_build_header(&cmd->cmd.common, nca);
> +
> + return 0;
> +}
> +
> static struct ncsi_cmd_handler {
> unsigned char type;
> int payload;
> @@ -244,7 +263,7 @@ static struct ncsi_cmd_handler {
> { NCSI_PKT_CMD_GNS, 0, ncsi_cmd_handler_default },
> { NCSI_PKT_CMD_GNPTS, 0, ncsi_cmd_handler_default },
> { NCSI_PKT_CMD_GPS, 0, ncsi_cmd_handler_default },
> - { NCSI_PKT_CMD_OEM, 0, NULL },
> + { NCSI_PKT_CMD_OEM, -1, ncsi_cmd_handler_oem },
> { NCSI_PKT_CMD_PLDM, 0, NULL },
> { NCSI_PKT_CMD_GPUUID, 0, ncsi_cmd_handler_default }
> };
> @@ -316,8 +335,13 @@ int ncsi_xmit_cmd(struct ncsi_cmd_arg *nca)
> return -ENOENT;
> }
>
> - /* Get packet payload length and allocate the request */
> - nca->payload = nch->payload;
> + /* Get packet payload length and allocate the request
> + * It is expected that if length set as negative in
> + * handler structure means caller is initializing it
> + * and setting length in nca before calling xmit function
> + */
> + if (nch->payload >= 0)
> + nca->payload = nch->payload;
> nr = ncsi_alloc_command(nca);
> if (!nr)
> return -ENOMEM;
> diff --git a/net/ncsi/ncsi-pkt.h b/net/ncsi/ncsi-pkt.h
> index 91b4b66438df..0f2087c8d42a 100644
> --- a/net/ncsi/ncsi-pkt.h
> +++ b/net/ncsi/ncsi-pkt.h
> @@ -151,6 +151,20 @@ struct ncsi_cmd_snfc_pkt {
> unsigned char pad[22];
> };
>
> +/* OEM Request Command as per NCSI Specification */
> +struct ncsi_cmd_oem_pkt {
> + struct ncsi_cmd_pkt_hdr cmd; /* Command header */
> + __be32 mfr_id; /* Manufacture ID */
> + unsigned char data[]; /* OEM Payload Data */
> +};
> +
> +/* OEM Response Packet as per NCSI Specification */
> +struct ncsi_rsp_oem_pkt {
> + struct ncsi_rsp_pkt_hdr rsp; /* Command header */
> + __be32 mfr_id; /* Manufacture ID */
> + unsigned char data[]; /* Payload data */
> +};
> +
> /* Get Link Status */
> struct ncsi_rsp_gls_pkt {
> struct ncsi_rsp_pkt_hdr rsp; /* Response header */
> diff --git a/net/ncsi/ncsi-rsp.c b/net/ncsi/ncsi-rsp.c
> index 930c1d3796f0..d66b34749027 100644
> --- a/net/ncsi/ncsi-rsp.c
> +++ b/net/ncsi/ncsi-rsp.c
> @@ -596,6 +596,47 @@ static int ncsi_rsp_handler_snfc(struct ncsi_request *nr)
> return 0;
> }
>
> +static struct ncsi_rsp_oem_handler {
> + unsigned int mfr_id;
> + int (*handler)(struct ncsi_request *nr);
> +} ncsi_rsp_oem_handlers[] = {
> + { NCSI_OEM_MFR_MLX_ID, NULL },
> + { NCSI_OEM_MFR_BCM_ID, NULL }
> +};
> +
> +/* Response handler for OEM command */
> +static int ncsi_rsp_handler_oem(struct ncsi_request *nr)
> +{
> + struct ncsi_rsp_oem_pkt *rsp;
> + struct ncsi_rsp_oem_handler *nrh = NULL;
> + unsigned int mfr_id, i;
> +
> + /* Get the response header */
> + rsp = (struct ncsi_rsp_oem_pkt *)skb_network_header(nr->rsp);
> + mfr_id = ntohl(rsp->mfr_id);
> +
> + /* Check for manufacturer id and Find the handler */
> + for (i = 0; i < ARRAY_SIZE(ncsi_rsp_oem_handlers); i++) {
> + if (ncsi_rsp_oem_handlers[i].mfr_id == mfr_id) {
> + if (ncsi_rsp_oem_handlers[i].handler)
> + nrh = &ncsi_rsp_oem_handlers[i];
> + else
> + nrh = NULL;
> +
> + break;
> + }
> + }
> +
> + if (!nrh) {
> + netdev_err(nr->ndp->ndev.dev, "Received unrecognized OEM packet with MFR-ID (0x%x)\n",
> + mfr_id);
> + return -ENOENT;
> + }
> +
> + /* Process the packet */
> + return nrh->handler(nr);
> +}
> +
> static int ncsi_rsp_handler_gvi(struct ncsi_request *nr)
> {
> struct ncsi_rsp_gvi_pkt *rsp;
> @@ -932,7 +973,7 @@ static struct ncsi_rsp_handler {
> { NCSI_PKT_RSP_GNS, 172, ncsi_rsp_handler_gns },
> { NCSI_PKT_RSP_GNPTS, 172, ncsi_rsp_handler_gnpts },
> { NCSI_PKT_RSP_GPS, 8, ncsi_rsp_handler_gps },
> - { NCSI_PKT_RSP_OEM, 0, NULL },
> + { NCSI_PKT_RSP_OEM, -1, ncsi_rsp_handler_oem },
> { NCSI_PKT_RSP_PLDM, 0, NULL },
> { NCSI_PKT_RSP_GPUUID, 20, ncsi_rsp_handler_gpuuid }
> };
^ permalink raw reply
* Re: [PATCH net-next] net: sched: remove unused helpers
From: David Miller @ 2018-10-05 4:42 UTC (permalink / raw)
To: jakub.kicinski; +Cc: jiri, netdev, oss-drivers
In-Reply-To: <20181005000751.24150-1-jakub.kicinski@netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Thu, 4 Oct 2018 17:07:51 -0700
> tcf_block_dev() doesn't seem to be used anywhere in the tree.
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Applied.
^ permalink raw reply
* Re: [PATCH net 0/4] bnxt_en: Misc. bug fixes.
From: David Miller @ 2018-10-05 4:42 UTC (permalink / raw)
To: michael.chan; +Cc: netdev
In-Reply-To: <1538713563-13878-1-git-send-email-michael.chan@broadcom.com>
From: Michael Chan <michael.chan@broadcom.com>
Date: Fri, 5 Oct 2018 00:25:59 -0400
> 4 small bug fixes related to setting firmware message enables bits, possible
> memory leak when probe fails, and ring accouting when RDMA driver is loaded.
>
> Please queue these for -stable as well. Thanks.
Series applied and queued up for -stable.
^ permalink raw reply
* RE: [PATCH 1/2] dt-bindings: net: add MDIO bus multiplexer driven by a regmap device
From: Pankaj Bansal @ 2018-10-05 4:32 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Florian Fainelli, netdev@vger.kernel.org, Alexandru Marginean
In-Reply-To: <20181005030818.GB7715@lunn.ch>
Hi Andrew
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Friday, October 5, 2018 8:38 AM
> To: Pankaj Bansal <pankaj.bansal@nxp.com>
> Cc: Florian Fainelli <f.fainelli@gmail.com>; netdev@vger.kernel.org;
> Alexandru Marginean <alexandru.marginean@nxp.com>
> Subject: Re: [PATCH 1/2] dt-bindings: net: add MDIO bus multiplexer driven
> by a regmap device
>
> > +i2c@2000000 {
> > + compatible = "fsl,vf610-i2c";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0x0 0x2000000 0x0 0x10000>;
> > + interrupts = <0 34 0x4>; // Level high type
> > + clock-names = "i2c";
> > + clocks = <&clockgen 4 7>;
> > + fsl-scl-gpio = <&gpio2 15 0>;
> > + status = "okay";
> > + /* The FPGA node */
> > + fpga@66 {
> > + compatible = "fsl,lx2160aqds-fpga", "fsl,fpga-qixis-i2c";
> > + reg = <0x66>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + mdio1_mux@54 {
> > + compatible = "mdio-mux-regmap", "mdio-mux";
> > + mdio-parent-bus = <&emdio2>; /* MDIO bus */
> > + reg = <0x54>; /* BRDCFG4 */
> > + mux-mask = <0x07>; /* EMI2_MDIO */
> > +
> > + #address-cells=<1>;
> > + #size-cells = <0>;
> > +
> > + mdio1_ioslot1@0 { // Slot 1
> > + reg = <0x00>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + phy1@1 {
>
> Hi Pankaj
>
> It looks like you have tab vs space issues.
I will fix the formatting error in V2
>
> > + reg = <1>;
> > + compatible = "ethernet-phy-id0210.7441";
> > + };
>
> A blank line after here please.
OK
> > + phy1@0 {
> > + reg = <0>;
> > + compatible = "ethernet-phy-id0210.7441";
> > + };
> > + };
>
> And here
Ok
>
> > + mdio1_ioslot2@1 { // Slot 2
> > + reg = <0x01>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + };
>
> and here.
Ok
>
> Andrew
^ permalink raw reply
* [PATCH net 4/4] bnxt_en: get the reduced max_irqs by the ones used by RDMA
From: Michael Chan @ 2018-10-05 4:26 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1538713563-13878-1-git-send-email-michael.chan@broadcom.com>
From: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
When getting the max rings supported, get the reduced max_irqs
by the ones used by RDMA.
If the number MSIX is the limiting factor, this bug may cause the
max ring count to be higher than it should be when RDMA driver is
loaded and may result in ring allocation failures.
Fixes: 30f529473ec9 ("bnxt_en: Do not modify max IRQ count after RDMA driver requests/frees IRQs.")
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 3718984..e2d9254 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -8622,7 +8622,7 @@ static void _bnxt_get_max_rings(struct bnxt *bp, int *max_rx, int *max_tx,
*max_tx = hw_resc->max_tx_rings;
*max_rx = hw_resc->max_rx_rings;
*max_cp = min_t(int, bnxt_get_max_func_cp_rings_for_en(bp),
- hw_resc->max_irqs);
+ hw_resc->max_irqs - bnxt_get_ulp_msix_num(bp));
*max_cp = min_t(int, *max_cp, hw_resc->max_stat_ctxs);
max_ring_grps = hw_resc->max_hw_ring_grps;
if (BNXT_CHIP_TYPE_NITRO_A0(bp) && BNXT_PF(bp)) {
--
2.5.1
^ permalink raw reply related
* [PATCH net 3/4] bnxt_en: free hwrm resources, if driver probe fails.
From: Michael Chan @ 2018-10-05 4:26 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1538713563-13878-1-git-send-email-michael.chan@broadcom.com>
From: Venkat Duvvuru <venkatkumar.duvvuru@broadcom.com>
When the driver probe fails, all the resources that were allocated prior
to the failure must be freed. However, hwrm dma response memory is not
getting freed.
This patch fixes the problem described above.
Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")
Signed-off-by: Venkat Duvvuru <venkatkumar.duvvuru@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 2564a92..3718984 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -3017,10 +3017,11 @@ static void bnxt_free_hwrm_resources(struct bnxt *bp)
{
struct pci_dev *pdev = bp->pdev;
- dma_free_coherent(&pdev->dev, PAGE_SIZE, bp->hwrm_cmd_resp_addr,
- bp->hwrm_cmd_resp_dma_addr);
-
- bp->hwrm_cmd_resp_addr = NULL;
+ if (bp->hwrm_cmd_resp_addr) {
+ dma_free_coherent(&pdev->dev, PAGE_SIZE, bp->hwrm_cmd_resp_addr,
+ bp->hwrm_cmd_resp_dma_addr);
+ bp->hwrm_cmd_resp_addr = NULL;
+ }
}
static int bnxt_alloc_hwrm_resources(struct bnxt *bp)
@@ -9057,6 +9058,7 @@ static int bnxt_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
bnxt_clear_int_mode(bp);
init_err_pci_clean:
+ bnxt_free_hwrm_resources(bp);
bnxt_cleanup_pci(bp);
init_err_free:
--
2.5.1
^ permalink raw reply related
* [PATCH net 2/4] bnxt_en: Fix enables field in HWRM_QUEUE_COS2BW_CFG request
From: Michael Chan @ 2018-10-05 4:26 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1538713563-13878-1-git-send-email-michael.chan@broadcom.com>
From: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
In HWRM_QUEUE_COS2BW_CFG request, enables field should have the bits
set only for the queue ids which are having the valid parameters.
This causes firmware to return error when the TC to hardware CoS queue
mapping is not 1:1 during DCBNL ETS setup.
Fixes: 2e8ef77ee0ff ("bnxt_en: Add TC to hardware QoS queue mapping logic.")
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c
index ddc98c3..a85d2be 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c
@@ -98,13 +98,13 @@ static int bnxt_hwrm_queue_cos2bw_cfg(struct bnxt *bp, struct ieee_ets *ets,
bnxt_hwrm_cmd_hdr_init(bp, &req, HWRM_QUEUE_COS2BW_CFG, -1, -1);
for (i = 0; i < max_tc; i++) {
- u8 qidx;
+ u8 qidx = bp->tc_to_qidx[i];
req.enables |= cpu_to_le32(
- QUEUE_COS2BW_CFG_REQ_ENABLES_COS_QUEUE_ID0_VALID << i);
+ QUEUE_COS2BW_CFG_REQ_ENABLES_COS_QUEUE_ID0_VALID <<
+ qidx);
memset(&cos2bw, 0, sizeof(cos2bw));
- qidx = bp->tc_to_qidx[i];
cos2bw.queue_id = bp->q_info[qidx].queue_id;
if (ets->tc_tsa[i] == IEEE_8021QAZ_TSA_STRICT) {
cos2bw.tsa =
--
2.5.1
^ permalink raw reply related
* [PATCH net 1/4] bnxt_en: Fix VNIC reservations on the PF.
From: Michael Chan @ 2018-10-05 4:26 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1538713563-13878-1-git-send-email-michael.chan@broadcom.com>
The enables bit for VNIC was set wrong when calling the HWRM_FUNC_CFG
firmware call to reserve VNICs. This has the effect that the firmware
will keep a large number of VNICs for the PF, and having very few for
VFs. DPDK driver running on the VFs, which requires more VNICs, may not
work properly as a result.
Fixes: 674f50a5b026 ("bnxt_en: Implement new method to reserve rings.")
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 0478e56..2564a92 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -4650,7 +4650,7 @@ __bnxt_hwrm_reserve_pf_rings(struct bnxt *bp, struct hwrm_func_cfg_input *req,
FUNC_CFG_REQ_ENABLES_NUM_STAT_CTXS : 0;
enables |= ring_grps ?
FUNC_CFG_REQ_ENABLES_NUM_HW_RING_GRPS : 0;
- enables |= vnics ? FUNC_VF_CFG_REQ_ENABLES_NUM_VNICS : 0;
+ enables |= vnics ? FUNC_CFG_REQ_ENABLES_NUM_VNICS : 0;
req->num_rx_rings = cpu_to_le16(rx_rings);
req->num_hw_ring_grps = cpu_to_le16(ring_grps);
--
2.5.1
^ 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