* [PATCH net-next 6/7] rxrpc: Add notification of end-of-Tx phase
From: David Howells @ 2017-08-29 12:27 UTC (permalink / raw)
To: netdev; +Cc: dhowells, linux-afs, linux-kernel
In-Reply-To: <150400960745.21371.15455867950162722742.stgit@warthog.procyon.org.uk>
Add a callback to rxrpc_kernel_send_data() so that a kernel service can get
a notification that the AF_RXRPC call has transitioned out the Tx phase and
is now waiting for a reply or a final ACK.
This is called from AF_RXRPC with the call state lock held so the
notification is guaranteed to come before any reply is passed back.
Further, modify the AFS filesystem to make use of this so that we don't have
to change the afs_call state before sending the last bit of data.
Signed-off-by: David Howells <dhowells@redhat.com>
---
Documentation/networking/rxrpc.txt | 12 +++++++++
fs/afs/rxrpc.c | 46 +++++++++++++++++++++++++++---------
include/net/af_rxrpc.h | 5 +++-
net/rxrpc/sendmsg.c | 34 +++++++++++++++++++++------
4 files changed, 77 insertions(+), 20 deletions(-)
diff --git a/Documentation/networking/rxrpc.txt b/Documentation/networking/rxrpc.txt
index 8c70ba5dee4d..92a3c3bd5ac3 100644
--- a/Documentation/networking/rxrpc.txt
+++ b/Documentation/networking/rxrpc.txt
@@ -818,10 +818,15 @@ The kernel interface functions are as follows:
(*) Send data through a call.
+ typedef void (*rxrpc_notify_end_tx_t)(struct sock *sk,
+ unsigned long user_call_ID,
+ struct sk_buff *skb);
+
int rxrpc_kernel_send_data(struct socket *sock,
struct rxrpc_call *call,
struct msghdr *msg,
- size_t len);
+ size_t len,
+ rxrpc_notify_end_tx_t notify_end_rx);
This is used to supply either the request part of a client call or the
reply part of a server call. msg.msg_iovlen and msg.msg_iov specify the
@@ -832,6 +837,11 @@ The kernel interface functions are as follows:
The msg must not specify a destination address, control data or any flags
other than MSG_MORE. len is the total amount of data to transmit.
+ notify_end_rx can be NULL or it can be used to specify a function to be
+ called when the call changes state to end the Tx phase. This function is
+ called with the call-state spinlock held to prevent any reply or final ACK
+ from being delivered first.
+
(*) Receive data from a call.
int rxrpc_kernel_recv_data(struct socket *sock,
diff --git a/fs/afs/rxrpc.c b/fs/afs/rxrpc.c
index 10743043d431..0bf191f0dbaf 100644
--- a/fs/afs/rxrpc.c
+++ b/fs/afs/rxrpc.c
@@ -292,6 +292,19 @@ static void afs_load_bvec(struct afs_call *call, struct msghdr *msg,
}
/*
+ * Advance the AFS call state when the RxRPC call ends the transmit phase.
+ */
+static void afs_notify_end_request_tx(struct sock *sock,
+ struct rxrpc_call *rxcall,
+ unsigned long call_user_ID)
+{
+ struct afs_call *call = (struct afs_call *)call_user_ID;
+
+ if (call->state == AFS_CALL_REQUESTING)
+ call->state = AFS_CALL_AWAIT_REPLY;
+}
+
+/*
* attach the data from a bunch of pages on an inode to a call
*/
static int afs_send_pages(struct afs_call *call, struct msghdr *msg)
@@ -310,14 +323,8 @@ static int afs_send_pages(struct afs_call *call, struct msghdr *msg)
bytes = msg->msg_iter.count;
nr = msg->msg_iter.nr_segs;
- /* Have to change the state *before* sending the last
- * packet as RxRPC might give us the reply before it
- * returns from sending the request.
- */
- if (first + nr - 1 >= last)
- call->state = AFS_CALL_AWAIT_REPLY;
- ret = rxrpc_kernel_send_data(afs_socket, call->rxcall,
- msg, bytes);
+ ret = rxrpc_kernel_send_data(afs_socket, call->rxcall, msg,
+ bytes, afs_notify_end_request_tx);
for (loop = 0; loop < nr; loop++)
put_page(bv[loop].bv_page);
if (ret < 0)
@@ -409,7 +416,8 @@ int afs_make_call(struct in_addr *addr, struct afs_call *call, gfp_t gfp,
if (!call->send_pages)
call->state = AFS_CALL_AWAIT_REPLY;
ret = rxrpc_kernel_send_data(afs_socket, rxcall,
- &msg, call->request_size);
+ &msg, call->request_size,
+ afs_notify_end_request_tx);
if (ret < 0)
goto error_do_abort;
@@ -741,6 +749,20 @@ static int afs_deliver_cm_op_id(struct afs_call *call)
}
/*
+ * Advance the AFS call state when an RxRPC service call ends the transmit
+ * phase.
+ */
+static void afs_notify_end_reply_tx(struct sock *sock,
+ struct rxrpc_call *rxcall,
+ unsigned long call_user_ID)
+{
+ struct afs_call *call = (struct afs_call *)call_user_ID;
+
+ if (call->state == AFS_CALL_REPLYING)
+ call->state = AFS_CALL_AWAIT_ACK;
+}
+
+/*
* send an empty reply
*/
void afs_send_empty_reply(struct afs_call *call)
@@ -759,7 +781,8 @@ void afs_send_empty_reply(struct afs_call *call)
msg.msg_flags = 0;
call->state = AFS_CALL_AWAIT_ACK;
- switch (rxrpc_kernel_send_data(afs_socket, call->rxcall, &msg, 0)) {
+ switch (rxrpc_kernel_send_data(afs_socket, call->rxcall, &msg, 0,
+ afs_notify_end_reply_tx)) {
case 0:
_leave(" [replied]");
return;
@@ -797,7 +820,8 @@ void afs_send_simple_reply(struct afs_call *call, const void *buf, size_t len)
msg.msg_flags = 0;
call->state = AFS_CALL_AWAIT_ACK;
- n = rxrpc_kernel_send_data(afs_socket, call->rxcall, &msg, len);
+ n = rxrpc_kernel_send_data(afs_socket, call->rxcall, &msg, len,
+ afs_notify_end_reply_tx);
if (n >= 0) {
/* Success */
_leave(" [replied]");
diff --git a/include/net/af_rxrpc.h b/include/net/af_rxrpc.h
index c172709787af..07a47ee6f783 100644
--- a/include/net/af_rxrpc.h
+++ b/include/net/af_rxrpc.h
@@ -21,6 +21,8 @@ struct rxrpc_call;
typedef void (*rxrpc_notify_rx_t)(struct sock *, struct rxrpc_call *,
unsigned long);
+typedef void (*rxrpc_notify_end_tx_t)(struct sock *, struct rxrpc_call *,
+ unsigned long);
typedef void (*rxrpc_notify_new_call_t)(struct sock *, struct rxrpc_call *,
unsigned long);
typedef void (*rxrpc_discard_new_call_t)(struct rxrpc_call *, unsigned long);
@@ -37,7 +39,8 @@ struct rxrpc_call *rxrpc_kernel_begin_call(struct socket *,
gfp_t,
rxrpc_notify_rx_t);
int rxrpc_kernel_send_data(struct socket *, struct rxrpc_call *,
- struct msghdr *, size_t);
+ struct msghdr *, size_t,
+ rxrpc_notify_end_tx_t);
int rxrpc_kernel_recv_data(struct socket *, struct rxrpc_call *,
void *, size_t, size_t *, bool, u32 *);
bool rxrpc_kernel_abort_call(struct socket *, struct rxrpc_call *,
diff --git a/net/rxrpc/sendmsg.c b/net/rxrpc/sendmsg.c
index bc7f0241d92b..344fdce89823 100644
--- a/net/rxrpc/sendmsg.c
+++ b/net/rxrpc/sendmsg.c
@@ -101,11 +101,23 @@ static inline void rxrpc_instant_resend(struct rxrpc_call *call, int ix)
}
/*
+ * Notify the owner of the call that the transmit phase is ended and the last
+ * packet has been queued.
+ */
+static void rxrpc_notify_end_tx(struct rxrpc_sock *rx, struct rxrpc_call *call,
+ rxrpc_notify_end_tx_t notify_end_tx)
+{
+ if (notify_end_tx)
+ notify_end_tx(&rx->sk, call, call->user_call_ID);
+}
+
+/*
* Queue a DATA packet for transmission, set the resend timeout and send the
* packet immediately
*/
-static void rxrpc_queue_packet(struct rxrpc_call *call, struct sk_buff *skb,
- bool last)
+static void rxrpc_queue_packet(struct rxrpc_sock *rx, struct rxrpc_call *call,
+ struct sk_buff *skb, bool last,
+ rxrpc_notify_end_tx_t notify_end_tx)
{
struct rxrpc_skb_priv *sp = rxrpc_skb(skb);
rxrpc_seq_t seq = sp->hdr.seq;
@@ -141,6 +153,7 @@ static void rxrpc_queue_packet(struct rxrpc_call *call, struct sk_buff *skb,
switch (call->state) {
case RXRPC_CALL_CLIENT_SEND_REQUEST:
call->state = RXRPC_CALL_CLIENT_AWAIT_REPLY;
+ rxrpc_notify_end_tx(rx, call, notify_end_tx);
break;
case RXRPC_CALL_SERVER_ACK_REQUEST:
call->state = RXRPC_CALL_SERVER_SEND_REPLY;
@@ -153,6 +166,7 @@ static void rxrpc_queue_packet(struct rxrpc_call *call, struct sk_buff *skb,
break;
case RXRPC_CALL_SERVER_SEND_REPLY:
call->state = RXRPC_CALL_SERVER_AWAIT_ACK;
+ rxrpc_notify_end_tx(rx, call, notify_end_tx);
break;
default:
break;
@@ -189,7 +203,8 @@ static void rxrpc_queue_packet(struct rxrpc_call *call, struct sk_buff *skb,
*/
static int rxrpc_send_data(struct rxrpc_sock *rx,
struct rxrpc_call *call,
- struct msghdr *msg, size_t len)
+ struct msghdr *msg, size_t len,
+ rxrpc_notify_end_tx_t notify_end_tx)
{
struct rxrpc_skb_priv *sp;
struct sk_buff *skb;
@@ -350,7 +365,9 @@ static int rxrpc_send_data(struct rxrpc_sock *rx,
if (ret < 0)
goto out;
- rxrpc_queue_packet(call, skb, !msg_data_left(msg) && !more);
+ rxrpc_queue_packet(rx, call, skb,
+ !msg_data_left(msg) && !more,
+ notify_end_tx);
skb = NULL;
}
} while (msg_data_left(msg) > 0);
@@ -611,7 +628,7 @@ int rxrpc_do_sendmsg(struct rxrpc_sock *rx, struct msghdr *msg, size_t len)
/* Reply phase not begun or not complete for service call. */
ret = -EPROTO;
} else {
- ret = rxrpc_send_data(rx, call, msg, len);
+ ret = rxrpc_send_data(rx, call, msg, len, NULL);
}
mutex_unlock(&call->user_mutex);
@@ -631,6 +648,7 @@ int rxrpc_do_sendmsg(struct rxrpc_sock *rx, struct msghdr *msg, size_t len)
* @call: The call to send data through
* @msg: The data to send
* @len: The amount of data to send
+ * @notify_end_tx: Notification that the last packet is queued.
*
* Allow a kernel service to send data on a call. The call must be in an state
* appropriate to sending data. No control data should be supplied in @msg,
@@ -638,7 +656,8 @@ int rxrpc_do_sendmsg(struct rxrpc_sock *rx, struct msghdr *msg, size_t len)
* more data to come, otherwise this data will end the transmission phase.
*/
int rxrpc_kernel_send_data(struct socket *sock, struct rxrpc_call *call,
- struct msghdr *msg, size_t len)
+ struct msghdr *msg, size_t len,
+ rxrpc_notify_end_tx_t notify_end_tx)
{
int ret;
@@ -656,7 +675,8 @@ int rxrpc_kernel_send_data(struct socket *sock, struct rxrpc_call *call,
case RXRPC_CALL_CLIENT_SEND_REQUEST:
case RXRPC_CALL_SERVER_ACK_REQUEST:
case RXRPC_CALL_SERVER_SEND_REPLY:
- ret = rxrpc_send_data(rxrpc_sk(sock->sk), call, msg, len);
+ ret = rxrpc_send_data(rxrpc_sk(sock->sk), call, msg, len,
+ notify_end_tx);
break;
case RXRPC_CALL_COMPLETE:
read_lock_bh(&call->state_lock);
^ permalink raw reply related
* [PATCH net-next 5/7] rxrpc: Remove some excess whitespace
From: David Howells @ 2017-08-29 12:27 UTC (permalink / raw)
To: netdev; +Cc: dhowells, linux-afs, linux-kernel
In-Reply-To: <150400960745.21371.15455867950162722742.stgit@warthog.procyon.org.uk>
Remove indentation from some blank lines.
Signed-off-by: David Howells <dhowells@redhat.com>
---
net/rxrpc/af_rxrpc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/rxrpc/af_rxrpc.c b/net/rxrpc/af_rxrpc.c
index a2ad4482376f..31e97f714ca9 100644
--- a/net/rxrpc/af_rxrpc.c
+++ b/net/rxrpc/af_rxrpc.c
@@ -591,13 +591,13 @@ static int rxrpc_getsockopt(struct socket *sock, int level, int optname,
char __user *optval, int __user *_optlen)
{
int optlen;
-
+
if (level != SOL_RXRPC)
return -EOPNOTSUPP;
if (get_user(optlen, _optlen))
return -EFAULT;
-
+
switch (optname) {
case RXRPC_SUPPORTED_CMSG:
if (optlen < sizeof(int))
@@ -606,7 +606,7 @@ static int rxrpc_getsockopt(struct socket *sock, int level, int optname,
put_user(sizeof(int), _optlen))
return -EFAULT;
return 0;
-
+
default:
return -EOPNOTSUPP;
}
^ permalink raw reply related
* [PATCH net-next 4/7] rxrpc: Don't negate call->error before returning it
From: David Howells @ 2017-08-29 12:27 UTC (permalink / raw)
To: netdev; +Cc: dhowells, linux-afs, linux-kernel
In-Reply-To: <150400960745.21371.15455867950162722742.stgit@warthog.procyon.org.uk>
call->error is stored as 0 or a negative error code. Don't negate this
value (ie. make it positive) before returning it from a kernel function
(though it should still be negated before passing to userspace through a
control message).
Signed-off-by: David Howells <dhowells@redhat.com>
---
net/rxrpc/sendmsg.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/rxrpc/sendmsg.c b/net/rxrpc/sendmsg.c
index b0d2cda6ec0a..bc7f0241d92b 100644
--- a/net/rxrpc/sendmsg.c
+++ b/net/rxrpc/sendmsg.c
@@ -61,7 +61,7 @@ static int rxrpc_wait_for_tx_window(struct rxrpc_sock *rx,
call->cong_cwnd + call->cong_extra))
break;
if (call->state >= RXRPC_CALL_COMPLETE) {
- ret = -call->error;
+ ret = call->error;
break;
}
if (signal_pending(current)) {
@@ -364,8 +364,8 @@ static int rxrpc_send_data(struct rxrpc_sock *rx,
call_terminated:
rxrpc_free_skb(skb, rxrpc_skb_tx_freed);
- _leave(" = %d", -call->error);
- return -call->error;
+ _leave(" = %d", call->error);
+ return call->error;
maybe_error:
if (copied)
@@ -660,7 +660,7 @@ int rxrpc_kernel_send_data(struct socket *sock, struct rxrpc_call *call,
break;
case RXRPC_CALL_COMPLETE:
read_lock_bh(&call->state_lock);
- ret = -call->error;
+ ret = call->error;
read_unlock_bh(&call->state_lock);
break;
default:
^ permalink raw reply related
* [PATCH net-next 3/7] rxrpc: Fix IPv6 support
From: David Howells @ 2017-08-29 12:27 UTC (permalink / raw)
To: netdev; +Cc: dhowells, linux-afs, linux-kernel
In-Reply-To: <150400960745.21371.15455867950162722742.stgit@warthog.procyon.org.uk>
Fix IPv6 support in AF_RXRPC in the following ways:
(1) When extracting the address from a received IPv4 packet, if the local
transport socket is open for IPv6 then fill out the sockaddr_rxrpc
struct for an IPv4-mapped-to-IPv6 AF_INET6 transport address instead
of an AF_INET one.
(2) When sending CHALLENGE or RESPONSE packets, the transport length needs
to be set from the sockaddr_rxrpc::transport_len field rather than
sizeof() on the IPv4 transport address.
(3) When processing an IPv4 ICMP packet received by an IPv6 socket, set up
the address correctly before searching for the affected peer.
Signed-off-by: David Howells <dhowells@redhat.com>
---
net/rxrpc/ar-internal.h | 4 ++--
net/rxrpc/call_accept.c | 2 +-
net/rxrpc/conn_object.c | 2 +-
net/rxrpc/local_event.c | 2 +-
net/rxrpc/output.c | 2 +-
net/rxrpc/peer_event.c | 6 ++++--
net/rxrpc/rxkad.c | 8 ++++----
net/rxrpc/utils.c | 23 +++++++++++++++++------
8 files changed, 31 insertions(+), 18 deletions(-)
diff --git a/net/rxrpc/ar-internal.h b/net/rxrpc/ar-internal.h
index 8cac66774de1..227e24794055 100644
--- a/net/rxrpc/ar-internal.h
+++ b/net/rxrpc/ar-internal.h
@@ -830,7 +830,6 @@ void rxrpc_process_connection(struct work_struct *);
*/
extern unsigned int rxrpc_connection_expiry;
-int rxrpc_extract_addr_from_skb(struct sockaddr_rxrpc *, struct sk_buff *);
struct rxrpc_connection *rxrpc_alloc_connection(gfp_t);
struct rxrpc_connection *rxrpc_find_connection_rcu(struct rxrpc_local *,
struct sk_buff *);
@@ -1060,7 +1059,8 @@ static inline void rxrpc_sysctl_exit(void) {}
/*
* utils.c
*/
-int rxrpc_extract_addr_from_skb(struct sockaddr_rxrpc *, struct sk_buff *);
+int rxrpc_extract_addr_from_skb(struct rxrpc_local *, struct sockaddr_rxrpc *,
+ struct sk_buff *);
static inline bool before(u32 seq1, u32 seq2)
{
diff --git a/net/rxrpc/call_accept.c b/net/rxrpc/call_accept.c
index ec3383f97d4c..cbd1701e813a 100644
--- a/net/rxrpc/call_accept.c
+++ b/net/rxrpc/call_accept.c
@@ -277,7 +277,7 @@ static struct rxrpc_call *rxrpc_alloc_incoming_call(struct rxrpc_sock *rx,
* anticipation - and to save on stack space.
*/
xpeer = b->peer_backlog[peer_tail];
- if (rxrpc_extract_addr_from_skb(&xpeer->srx, skb) < 0)
+ if (rxrpc_extract_addr_from_skb(local, &xpeer->srx, skb) < 0)
return NULL;
peer = rxrpc_lookup_incoming_peer(local, xpeer);
diff --git a/net/rxrpc/conn_object.c b/net/rxrpc/conn_object.c
index 929b50d5afe8..fe575798592f 100644
--- a/net/rxrpc/conn_object.c
+++ b/net/rxrpc/conn_object.c
@@ -72,7 +72,7 @@ struct rxrpc_connection *rxrpc_find_connection_rcu(struct rxrpc_local *local,
_enter(",%x", sp->hdr.cid & RXRPC_CIDMASK);
- if (rxrpc_extract_addr_from_skb(&srx, skb) < 0)
+ if (rxrpc_extract_addr_from_skb(local, &srx, skb) < 0)
goto not_found;
k.epoch = sp->hdr.epoch;
diff --git a/net/rxrpc/local_event.c b/net/rxrpc/local_event.c
index 540d3955c1bc..93b5d910b4a1 100644
--- a/net/rxrpc/local_event.c
+++ b/net/rxrpc/local_event.c
@@ -39,7 +39,7 @@ static void rxrpc_send_version_request(struct rxrpc_local *local,
_enter("");
- if (rxrpc_extract_addr_from_skb(&srx, skb) < 0)
+ if (rxrpc_extract_addr_from_skb(local, &srx, skb) < 0)
return;
msg.msg_name = &srx.transport;
diff --git a/net/rxrpc/output.c b/net/rxrpc/output.c
index 5bd2d0fa4a03..71e6f713fbe7 100644
--- a/net/rxrpc/output.c
+++ b/net/rxrpc/output.c
@@ -444,7 +444,7 @@ void rxrpc_reject_packets(struct rxrpc_local *local)
rxrpc_see_skb(skb, rxrpc_skb_rx_seen);
sp = rxrpc_skb(skb);
- if (rxrpc_extract_addr_from_skb(&srx, skb) == 0) {
+ if (rxrpc_extract_addr_from_skb(local, &srx, skb) == 0) {
msg.msg_namelen = srx.transport_len;
code = htonl(skb->priority);
diff --git a/net/rxrpc/peer_event.c b/net/rxrpc/peer_event.c
index 1ed9c0c2e94f..7f749505e699 100644
--- a/net/rxrpc/peer_event.c
+++ b/net/rxrpc/peer_event.c
@@ -37,6 +37,7 @@ static struct rxrpc_peer *rxrpc_lookup_peer_icmp_rcu(struct rxrpc_local *local,
memset(&srx, 0, sizeof(srx));
srx.transport_type = local->srx.transport_type;
+ srx.transport_len = local->srx.transport_len;
srx.transport.family = local->srx.transport.family;
/* Can we see an ICMP4 packet on an ICMP6 listening socket? and vice
@@ -45,7 +46,6 @@ static struct rxrpc_peer *rxrpc_lookup_peer_icmp_rcu(struct rxrpc_local *local,
switch (srx.transport.family) {
case AF_INET:
srx.transport.sin.sin_port = serr->port;
- srx.transport_len = sizeof(struct sockaddr_in);
switch (serr->ee.ee_origin) {
case SO_EE_ORIGIN_ICMP:
_net("Rx ICMP");
@@ -69,7 +69,6 @@ static struct rxrpc_peer *rxrpc_lookup_peer_icmp_rcu(struct rxrpc_local *local,
#ifdef CONFIG_AF_RXRPC_IPV6
case AF_INET6:
srx.transport.sin6.sin6_port = serr->port;
- srx.transport_len = sizeof(struct sockaddr_in6);
switch (serr->ee.ee_origin) {
case SO_EE_ORIGIN_ICMP6:
_net("Rx ICMP6");
@@ -79,6 +78,9 @@ static struct rxrpc_peer *rxrpc_lookup_peer_icmp_rcu(struct rxrpc_local *local,
break;
case SO_EE_ORIGIN_ICMP:
_net("Rx ICMP on v6 sock");
+ srx.transport.sin6.sin6_addr.s6_addr32[0] = 0;
+ srx.transport.sin6.sin6_addr.s6_addr32[1] = 0;
+ srx.transport.sin6.sin6_addr.s6_addr32[2] = htonl(0xffff);
memcpy(srx.transport.sin6.sin6_addr.s6_addr + 12,
skb_network_header(skb) + serr->addr_offset,
sizeof(struct in_addr));
diff --git a/net/rxrpc/rxkad.c b/net/rxrpc/rxkad.c
index 34c86d2bcae5..c38b3a1de56c 100644
--- a/net/rxrpc/rxkad.c
+++ b/net/rxrpc/rxkad.c
@@ -634,8 +634,8 @@ static int rxkad_issue_challenge(struct rxrpc_connection *conn)
challenge.min_level = htonl(0);
challenge.__padding = 0;
- msg.msg_name = &conn->params.peer->srx.transport.sin;
- msg.msg_namelen = sizeof(conn->params.peer->srx.transport.sin);
+ msg.msg_name = &conn->params.peer->srx.transport;
+ msg.msg_namelen = conn->params.peer->srx.transport_len;
msg.msg_control = NULL;
msg.msg_controllen = 0;
msg.msg_flags = 0;
@@ -689,8 +689,8 @@ static int rxkad_send_response(struct rxrpc_connection *conn,
_enter("");
- msg.msg_name = &conn->params.peer->srx.transport.sin;
- msg.msg_namelen = sizeof(conn->params.peer->srx.transport.sin);
+ msg.msg_name = &conn->params.peer->srx.transport;
+ msg.msg_namelen = conn->params.peer->srx.transport_len;
msg.msg_control = NULL;
msg.msg_controllen = 0;
msg.msg_flags = 0;
diff --git a/net/rxrpc/utils.c b/net/rxrpc/utils.c
index ff7af71c4b49..e801171fa351 100644
--- a/net/rxrpc/utils.c
+++ b/net/rxrpc/utils.c
@@ -17,17 +17,28 @@
/*
* Fill out a peer address from a socket buffer containing a packet.
*/
-int rxrpc_extract_addr_from_skb(struct sockaddr_rxrpc *srx, struct sk_buff *skb)
+int rxrpc_extract_addr_from_skb(struct rxrpc_local *local,
+ struct sockaddr_rxrpc *srx,
+ struct sk_buff *skb)
{
memset(srx, 0, sizeof(*srx));
switch (ntohs(skb->protocol)) {
case ETH_P_IP:
- srx->transport_type = SOCK_DGRAM;
- srx->transport_len = sizeof(srx->transport.sin);
- srx->transport.sin.sin_family = AF_INET;
- srx->transport.sin.sin_port = udp_hdr(skb)->source;
- srx->transport.sin.sin_addr.s_addr = ip_hdr(skb)->saddr;
+ if (local->srx.transport.family == AF_INET6) {
+ srx->transport_type = SOCK_DGRAM;
+ srx->transport_len = sizeof(srx->transport.sin6);
+ srx->transport.sin6.sin6_family = AF_INET6;
+ srx->transport.sin6.sin6_port = udp_hdr(skb)->source;
+ srx->transport.sin6.sin6_addr.s6_addr32[2] = htonl(0xffff);
+ srx->transport.sin6.sin6_addr.s6_addr32[3] = ip_hdr(skb)->saddr;
+ } else {
+ srx->transport_type = SOCK_DGRAM;
+ srx->transport_len = sizeof(srx->transport.sin);
+ srx->transport.sin.sin_family = AF_INET;
+ srx->transport.sin.sin_port = udp_hdr(skb)->source;
+ srx->transport.sin.sin_addr.s_addr = ip_hdr(skb)->saddr;
+ }
return 0;
#ifdef CONFIG_AF_RXRPC_IPV6
^ permalink raw reply related
* [PATCH net-next 2/7] rxrpc: Use correct timestamp from Kerberos 5 ticket
From: David Howells @ 2017-08-29 12:27 UTC (permalink / raw)
To: netdev; +Cc: dhowells, linux-afs, linux-kernel
In-Reply-To: <150400960745.21371.15455867950162722742.stgit@warthog.procyon.org.uk>
When an XDR-encoded Kerberos 5 ticket is added as an rxrpc-type key, the
expiry time should be drawn from the k5 part of the token union (which was
what was filled in), rather than the kad part of the union.
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David Howells <dhowells@redhat.com>
---
net/rxrpc/key.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/rxrpc/key.c b/net/rxrpc/key.c
index e2d36619b53a..e7f6b8823eb6 100644
--- a/net/rxrpc/key.c
+++ b/net/rxrpc/key.c
@@ -536,7 +536,7 @@ static int rxrpc_preparse_xdr_rxk5(struct key_preparsed_payload *prep,
pptoken = &(*pptoken)->next)
continue;
*pptoken = token;
- expiry = rxrpc_u32_to_time64(token->kad->expiry);
+ expiry = rxrpc_u32_to_time64(token->k5->endtime);
if (expiry < prep->expiry)
prep->expiry = expiry;
^ permalink raw reply related
* [PATCH net-next 1/7] net: rxrpc: Replace time_t type with time64_t type
From: David Howells @ 2017-08-29 12:26 UTC (permalink / raw)
To: netdev; +Cc: dhowells, linux-afs, linux-kernel
In-Reply-To: <150400960745.21371.15455867950162722742.stgit@warthog.procyon.org.uk>
From: Baolin Wang <baolin.wang@linaro.org>
Since the 'expiry' variable of 'struct key_preparsed_payload' has been
changed to 'time64_t' type, which is year 2038 safe on 32bits system.
In net/rxrpc subsystem, we need convert 'u32' type to 'time64_t' type
when copying ticket expires time to 'prep->expiry', then this patch
introduces two helper functions to help convert 'u32' to 'time64_t'
type.
This patch also uses ktime_get_real_seconds() to get current time instead
of get_seconds() which is not year 2038 safe on 32bits system.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: David Howells <dhowells@redhat.com>
---
include/keys/rxrpc-type.h | 23 +++++++++++++++++++++++
net/rxrpc/ar-internal.h | 2 +-
net/rxrpc/key.c | 22 ++++++++++++++--------
net/rxrpc/rxkad.c | 14 +++++++-------
4 files changed, 45 insertions(+), 16 deletions(-)
diff --git a/include/keys/rxrpc-type.h b/include/keys/rxrpc-type.h
index 5de0673f333b..8cf829dbf20e 100644
--- a/include/keys/rxrpc-type.h
+++ b/include/keys/rxrpc-type.h
@@ -127,4 +127,27 @@ struct rxrpc_key_data_v1 {
#define AFSTOKEN_K5_ADDRESSES_MAX 16 /* max K5 addresses */
#define AFSTOKEN_K5_AUTHDATA_MAX 16 /* max K5 pieces of auth data */
+/*
+ * Truncate a time64_t to the range from 1970 to 2106 as in the network
+ * protocol.
+ */
+static inline u32 rxrpc_time64_to_u32(time64_t time)
+{
+ if (time < 0)
+ return 0;
+
+ if (time > UINT_MAX)
+ return UINT_MAX;
+
+ return (u32)time;
+}
+
+/*
+ * Extend u32 back to time64_t using the same 1970-2106 range.
+ */
+static inline time64_t rxrpc_u32_to_time64(u32 time)
+{
+ return (time64_t)time;
+}
+
#endif /* _KEYS_RXRPC_TYPE_H */
diff --git a/net/rxrpc/ar-internal.h b/net/rxrpc/ar-internal.h
index 8c0db9b3e4ab..8cac66774de1 100644
--- a/net/rxrpc/ar-internal.h
+++ b/net/rxrpc/ar-internal.h
@@ -894,7 +894,7 @@ extern struct key_type key_type_rxrpc_s;
int rxrpc_request_key(struct rxrpc_sock *, char __user *, int);
int rxrpc_server_keyring(struct rxrpc_sock *, char __user *, int);
-int rxrpc_get_server_data_key(struct rxrpc_connection *, const void *, time_t,
+int rxrpc_get_server_data_key(struct rxrpc_connection *, const void *, time64_t,
u32);
/*
diff --git a/net/rxrpc/key.c b/net/rxrpc/key.c
index 54369225766e..e2d36619b53a 100644
--- a/net/rxrpc/key.c
+++ b/net/rxrpc/key.c
@@ -92,6 +92,7 @@ static int rxrpc_preparse_xdr_rxkad(struct key_preparsed_payload *prep,
const __be32 *xdr, unsigned int toklen)
{
struct rxrpc_key_token *token, **pptoken;
+ time64_t expiry;
size_t plen;
u32 tktlen;
@@ -158,8 +159,9 @@ static int rxrpc_preparse_xdr_rxkad(struct key_preparsed_payload *prep,
pptoken = &(*pptoken)->next)
continue;
*pptoken = token;
- if (token->kad->expiry < prep->expiry)
- prep->expiry = token->kad->expiry;
+ expiry = rxrpc_u32_to_time64(token->kad->expiry);
+ if (expiry < prep->expiry)
+ prep->expiry = expiry;
_leave(" = 0");
return 0;
@@ -433,6 +435,7 @@ static int rxrpc_preparse_xdr_rxk5(struct key_preparsed_payload *prep,
struct rxrpc_key_token *token, **pptoken;
struct rxk5_key *rxk5;
const __be32 *end_xdr = xdr + (toklen >> 2);
+ time64_t expiry;
int ret;
_enter(",{%x,%x,%x,%x},%u",
@@ -533,8 +536,9 @@ static int rxrpc_preparse_xdr_rxk5(struct key_preparsed_payload *prep,
pptoken = &(*pptoken)->next)
continue;
*pptoken = token;
- if (token->kad->expiry < prep->expiry)
- prep->expiry = token->kad->expiry;
+ expiry = rxrpc_u32_to_time64(token->kad->expiry);
+ if (expiry < prep->expiry)
+ prep->expiry = expiry;
_leave(" = 0");
return 0;
@@ -691,6 +695,7 @@ static int rxrpc_preparse(struct key_preparsed_payload *prep)
{
const struct rxrpc_key_data_v1 *v1;
struct rxrpc_key_token *token, **pp;
+ time64_t expiry;
size_t plen;
u32 kver;
int ret;
@@ -777,8 +782,9 @@ static int rxrpc_preparse(struct key_preparsed_payload *prep)
while (*pp)
pp = &(*pp)->next;
*pp = token;
- if (token->kad->expiry < prep->expiry)
- prep->expiry = token->kad->expiry;
+ expiry = rxrpc_u32_to_time64(token->kad->expiry);
+ if (expiry < prep->expiry)
+ prep->expiry = expiry;
token = NULL;
ret = 0;
@@ -955,7 +961,7 @@ int rxrpc_server_keyring(struct rxrpc_sock *rx, char __user *optval,
*/
int rxrpc_get_server_data_key(struct rxrpc_connection *conn,
const void *session_key,
- time_t expiry,
+ time64_t expiry,
u32 kvno)
{
const struct cred *cred = current_cred();
@@ -982,7 +988,7 @@ int rxrpc_get_server_data_key(struct rxrpc_connection *conn,
data.kver = 1;
data.v1.security_index = RXRPC_SECURITY_RXKAD;
data.v1.ticket_length = 0;
- data.v1.expiry = expiry;
+ data.v1.expiry = rxrpc_time64_to_u32(expiry);
data.v1.kvno = 0;
memcpy(&data.v1.session_key, session_key, sizeof(data.v1.session_key));
diff --git a/net/rxrpc/rxkad.c b/net/rxrpc/rxkad.c
index 46d1a1f0b55b..34c86d2bcae5 100644
--- a/net/rxrpc/rxkad.c
+++ b/net/rxrpc/rxkad.c
@@ -854,7 +854,7 @@ static int rxkad_decrypt_ticket(struct rxrpc_connection *conn,
struct sk_buff *skb,
void *ticket, size_t ticket_len,
struct rxrpc_crypt *_session_key,
- time_t *_expiry,
+ time64_t *_expiry,
u32 *_abort_code)
{
struct skcipher_request *req;
@@ -864,7 +864,7 @@ static int rxkad_decrypt_ticket(struct rxrpc_connection *conn,
struct in_addr addr;
unsigned int life;
const char *eproto;
- time_t issue, now;
+ time64_t issue, now;
bool little_endian;
int ret;
u32 abort_code;
@@ -960,15 +960,15 @@ static int rxkad_decrypt_ticket(struct rxrpc_connection *conn,
if (little_endian) {
__le32 stamp;
memcpy(&stamp, p, 4);
- issue = le32_to_cpu(stamp);
+ issue = rxrpc_u32_to_time64(le32_to_cpu(stamp));
} else {
__be32 stamp;
memcpy(&stamp, p, 4);
- issue = be32_to_cpu(stamp);
+ issue = rxrpc_u32_to_time64(be32_to_cpu(stamp));
}
p += 4;
- now = get_seconds();
- _debug("KIV ISSUE: %lx [%lx]", issue, now);
+ now = ktime_get_real_seconds();
+ _debug("KIV ISSUE: %llx [%llx]", issue, now);
/* check the ticket is in date */
if (issue > now) {
@@ -1053,7 +1053,7 @@ static int rxkad_verify_response(struct rxrpc_connection *conn,
struct rxrpc_skb_priv *sp = rxrpc_skb(skb);
struct rxrpc_crypt session_key;
const char *eproto;
- time_t expiry;
+ time64_t expiry;
void *ticket;
u32 abort_code, version, kvno, ticket_len, level;
__be32 csum;
^ permalink raw reply related
* [PATCH net-next 0/7] rxrpc: Miscellany
From: David Howells @ 2017-08-29 12:26 UTC (permalink / raw)
To: netdev; +Cc: dhowells, linux-afs, linux-kernel
Here are a number of patches that make some changes/fixes and add a couple
of extensions to AF_RXRPC for kernel services to use. The changes and
fixes are:
(1) Use time64_t rather than u32 outside of protocol or
UAPI-representative structures.
(2) Use the correct time stamp when loading a key from an XDR-encoded
Kerberos 5 key.
(3) Fix IPv6 support.
(4) Fix some places where the error code is being incorrectly made
positive before returning.
(5) Remove some white space.
And the extensions:
(6) Add an end-of-Tx phase notification, thereby allowing kAFS to
transition the state on its own call record at the correct point,
rather than having to do it in advance and risk non-completion of the
call in the wrong state.
(7) Allow a kernel client call to be retried if it fails on a network
error, thereby making it possible for kAFS to iterate over a number of
IP addresses without having to reload the Tx queue and re-encrypt data
each time.
The patches can be found here also:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-next
Tagged thusly:
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
rxrpc-next-20170829
David
---
Baolin Wang (1):
net: rxrpc: Replace time_t type with time64_t type
David Howells (6):
rxrpc: Use correct timestamp from Kerberos 5 ticket
rxrpc: Fix IPv6 support
rxrpc: Don't negate call->error before returning it
rxrpc: Remove some excess whitespace
rxrpc: Add notification of end-of-Tx phase
rxrpc: Allow failed client calls to be retried
Documentation/networking/rxrpc.txt | 57 ++++++++++++++++++++
fs/afs/rxrpc.c | 46 ++++++++++++----
include/keys/rxrpc-type.h | 23 ++++++++
include/net/af_rxrpc.h | 21 +++++++
net/rxrpc/af_rxrpc.c | 75 +++++++++++++++++++++++++-
net/rxrpc/ar-internal.h | 25 ++++-----
net/rxrpc/call_accept.c | 2 -
net/rxrpc/call_object.c | 102 ++++++++++++++++++++++++++++++++++--
net/rxrpc/conn_client.c | 17 +++++-
net/rxrpc/conn_object.c | 2 -
net/rxrpc/key.c | 22 +++++---
net/rxrpc/local_event.c | 2 -
net/rxrpc/output.c | 2 -
net/rxrpc/peer_event.c | 6 +-
net/rxrpc/rxkad.c | 22 ++++----
net/rxrpc/sendmsg.c | 62 +++++++++++++++-------
net/rxrpc/utils.c | 23 ++++++--
17 files changed, 419 insertions(+), 90 deletions(-)
^ permalink raw reply
* Re: [PATCH] DSA support for Micrel KSZ8895
From: Andrew Lunn @ 2017-08-29 12:26 UTC (permalink / raw)
To: Pavel Machek
Cc: Maxim Uvarov, Woojung.Huh, nathan.leigh.conrad, Vivien Didelot,
Florian Fainelli, netdev, linux-kernel, Tristram.Ha
In-Reply-To: <20170829074130.GA31303@amd>
> But the MDIO emaulation code is from their driver, after lots of
> deletions.
Is this driver supposed to run on lots of different OSs? That would
explain why they ignored the Linux MDIO and PHY layers.
If possible, please make use of the Linux infrastructure.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v3 02/13] phy: add the mvebu cp110 comphy driver
From: Kishon Vijay Abraham I @ 2017-08-29 12:25 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, andrew, jason, sebastian.hesselbarth, gregory.clement,
thomas.petazzoni, nadavh, linux, linux-kernel, mw, stefanc,
miquel.raynal, netdev
In-Reply-To: <20170829112340.GB31552@kwain>
Hi,
On Tuesday 29 August 2017 04:53 PM, Antoine Tenart wrote:
> Hi Kishon,
>
> On Tue, Aug 29, 2017 at 04:34:17PM +0530, Kishon Vijay Abraham I wrote:
>> On Monday 28 August 2017 08:27 PM, Antoine Tenart wrote:
>>>
>>> +config PHY_MVEBU_CP110_COMPHY
>>> + tristate "Marvell CP110 comphy driver"
>>> + depends on ARCH_MVEBU && OF
>>
>> (ARCH_MVEBU || COMPILE_TEST) above..
>
> Sure, I'll update.
>
>>> +static const struct mvebu_comhy_conf mvebu_comphy_cp110_modes[] = {
>>> + /* lane 0 */
>>> + MVEBU_COMPHY_CONF(0, 1, PHY_MODE_SGMII, 0x1),
>>> + /* lane 1 */
>>> + MVEBU_COMPHY_CONF(1, 2, PHY_MODE_SGMII, 0x1),
>>> + /* lane 2 */
>>> + MVEBU_COMPHY_CONF(2, 0, PHY_MODE_SGMII, 0x1),
>>> + MVEBU_COMPHY_CONF(2, 0, PHY_MODE_10GKR, 0x1),
>>> + /* lane 3 */
>>> + MVEBU_COMPHY_CONF(3, 1, PHY_MODE_SGMII, 0x2),
>>> + /* lane 4 */
>>> + MVEBU_COMPHY_CONF(4, 0, PHY_MODE_SGMII, 0x2),
>>> + MVEBU_COMPHY_CONF(4, 0, PHY_MODE_10GKR, 0x2),
>>> + MVEBU_COMPHY_CONF(4, 1, PHY_MODE_SGMII, 0x1),
>>> + /* lane 5 */
>>> + MVEBU_COMPHY_CONF(5, 2, PHY_MODE_SGMII, 0x1),
>>> +};
>>
>> IMHO all the lane and mode configuration should come from dt. That would make
>> it more reusable when comphy is configured differently.
>
> These connexions between engines and the comphy lanes are inside the
> SoC. They won't change for a given SoC, and the actual configuration is
> at the board level to know what is connected to the output of a given
> lane, which is already described into the dt (the lane phandle).
>
> So I think we can keep this inside the driver, and we'll had other
> tables if the same comphy is ever used in another SoC.
>
> What do you think?
I'd like to avoid adding tables for every SoC. These are configuration details
and can come from dt.
Thanks
Kishon
^ permalink raw reply
* Re: [PATCH net-next v3 01/13] phy: add sgmii and 10gkr modes to the phy_mode enum
From: Kishon Vijay Abraham I @ 2017-08-29 12:21 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, andrew, jason, sebastian.hesselbarth, gregory.clement,
thomas.petazzoni, nadavh, linux, linux-kernel, mw, stefanc,
miquel.raynal, netdev
In-Reply-To: <20170829112717.GC31552@kwain>
Hi,
On Tuesday 29 August 2017 04:57 PM, Antoine Tenart wrote:
> Hi Kishon,
>
> On Tue, Aug 29, 2017 at 04:08:29PM +0530, Kishon Vijay Abraham I wrote:
>> On Monday 28 August 2017 08:27 PM, Antoine Tenart wrote:
>>> This patch adds more generic PHY modes to the phy_mode enum, to
>>> allow configuring generic PHYs to the SGMII and/or the 10GKR mode
>>> by using the set_mode callback.
>>>
>>> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
>>
>> Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
>
> Does this means the generic PHY patches of this series can go through
> the net-next tree (once all the comments are taken into account)?
yeah.. I'm already done with my pull request for 4.14 to Greg KH. As long as it
doesn't cause any conflicts to Linus, it should be okay to merge it in net-next.
Thanks
Kishon
^ permalink raw reply
* Re: [PATCH 0/4] irda: move it to drivers/staging so we can delete it
From: Geert Uytterhoeven @ 2017-08-29 12:11 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Stefano Brivio, driverdevel, Samuel Ortiz,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
David S. Miller
In-Reply-To: <20170829112805.GB14571@kroah.com>
Hi Greg,
On Tue, Aug 29, 2017 at 1:28 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Tue, Aug 29, 2017 at 01:11:31PM +0200, Stefano Brivio wrote:
>> On Tue, 29 Aug 2017 12:59:00 +0200
>> Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> > On Sun, Aug 27, 2017 at 5:03 PM, Greg Kroah-Hartman
>> > <gregkh@linuxfoundation.org> wrote:
>> > > The IRDA code has long been obsolete and broken. So, to keep people
>> > > from trying to use it, and to prevent people from having to maintain it,
>> > > let's move it to drivers/staging/ so that we can delete it entirely from
>> > > the kernel in a few releases.
>> >
>> > (diving into an early boot crash)
>> >
>> > Have you tried running this? ;-)
>> >
>> > irda_init() and net_dev_init() are both subsys_initcall()s.
>> > But the former now runs before the latter, leading to:
>> >
>> > Unable to handle kernel NULL pointer dereference at virtual address 00000004
>>
>> Should be fixed by https://patchwork.ozlabs.org/patch/807006/
>> ("[net-next] staging: irda: force to be a kernel module") I guess...
>
> Yup, that's the fix for this issue.
>
> Geert, does that fix the problem for you?
Thanks, that patch fixes the crash, obviously.
It does mean you can no longer have IrDA in a non-modular kernel.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: Fwd: DA850-evm MAC Address is random
From: Adam Ford @ 2017-08-29 12:02 UTC (permalink / raw)
To: Sekhar Nori; +Cc: Tony Lindgren, Grygorii Strashko, linux-omap, netdev
In-Reply-To: <f0f5e11f-cd7a-cb86-58b5-8ce44cdbc032@ti.com>
On Tue, Aug 29, 2017 at 6:42 AM, Sekhar Nori <nsekhar@ti.com> wrote:
> On Tuesday 29 August 2017 03:53 PM, Adam Ford wrote:
>> On Tue, Aug 29, 2017 at 3:23 AM, Sekhar Nori <nsekhar@ti.com> wrote:
>>> On Tuesday 29 August 2017 02:42 AM, Tony Lindgren wrote:
>>>> * Adam Ford <aford173@gmail.com> [170828 13:33]:
>>>>> On Mon, Aug 28, 2017 at 1:54 PM, Grygorii Strashko
>>>>> <grygorii.strashko@ti.com> wrote:
>>>>>> Cc: Sekhar
>>>>>>
>>>>>> On 08/28/2017 10:32 AM, Adam Ford wrote:
>>>>>>>
>>>>>>> The davinvi_emac MAC address seems to attempt a call to
>>>>>>> ti_cm_get_macid in cpsw-common.c but it returns the message
>>>>>>> 'davinci_emac davinci_emac.1: incompatible machine/device type for
>>>>>>> reading mac address ' and then generates a random MAC address.
>>>>>>>
>>>>>>> The function appears to lookup varions boards using
>>>>>>> 'of_machine_is_compaible' and supports dm8148, am33xx, am3517, dm816,
>>>>>>> am4372 and dra7. I don't see the ti,davinci-dm6467-emac which is
>>>>>>> what's shown in the da850 device tree.
>>>>>>>
>>>>>>> Is there a patch somewhere for supporting the da850-evm?
>>>>>>
>>>>>>
>>>>>> Not sure if MAC address can be read from Control module.
>>>>>> May be Sekhar can say more?
>>>>>
>>>>> My understanding is that the MAC address is programmed by Logic PD
>>>>> into the SPI flash. The Bootloader reads this from either SPI or its
>>>>> env variables. Looking at the partition info listed in the
>>>>> da850-evm.dts file, it appears as if they've reserved space for it.
>>>>> Unfortunately, I don't see any code that reads it out. I was hoping
>>>
>>> This code is present in U-Boot sources at
>>> board/davinci/da8xxevm/da850evm.c. See the function get_mac_addr() and
>>> its usage in misc_init_r().
>>>
>>>>> there might be a way to just pass cmdline parameter from the
>>>>> bootloader to the kernel to accept the MAC address.
>>>>>
>>>>>>
>>>>>>>
>>>>>>> If not, is there a way to pass the MAC address from U-Boot to the
>>>>>>> driver so it doesn't generate a random MAC?
>>>>>>
>>>>>>
>>>>>> "local-mac-address" dt porp
>>>>>
>>>>> The downside here, is that we'd have to have the Bootloader modify the
>>>>> device tree.
>>>>
>>>> That piece of code exists somewhere in u-boot already. Note how
>>>
>>> Yes, it is fdt_fixup_ethernet() and its usage is in common/image-fdt.c.
>>>
>>>> we are populating the mac address for USB Ethernet drivers in
>>>> u-boot and then the Ethernet driver code parses it. See commit
>>>> 055d31de7158 ("ARM: omap3: beagleboard-xm: dt: Add ethernet to
>>>> the device tree") for some more information.
>>>>
>>>> I think u-boot needs the ethernet alias for finding the interface.
>>>
>>> That's exactly what was missing. I have sent a patch for fixing that and
>>> copied you there.
>>
>> Thanks for doing that.
>>
>>>
>>> Adam, if I can get your Tested-by, I will make an attempt to send it for
>>> v4.13 itself.
>>
>> I will test it. Do need to run some instruction or do something
>> special in U-Boot to pass this in the proper place for the kernel to
>> pull it? Tony's patch reference showed
>> command for fdt set, but I am not sure I fully understand the
>> parameters that went along with that.
>
> Nope, just applying the patch and booting the with the new dtb should
> result in the random mac address going away.
Unfortunately, I am not seeing any change with the patch (at least
with Kernel 4.12.9 from stable).
netconsole: network logging started
davinci_emac davinci_emac.1: incompatible machine/device type for
reading mac address
davinci_emac davinci_emac.1: using random MAC addr: ee:74:c3:3a:15:be
Looking at the source for cpsw-common.c function ti_cm_get_macid()
doesn't have a case for the ti,davinci-dm6467-emac so I wonder if
there might be more to it.
adam
>
> Thanks,
> Sekhar
^ permalink raw reply
* Attention Dear Friend,
From: Mr.Robert Koffi @ 2017-08-29 11:49 UTC (permalink / raw)
Attention Dear Friend,
Compliment of the day to you, I sent you a mail a couple of day ago
about a transaction and haven't heard from you since then.The message
was to solicit your partnership to transfer the sum of ($14 million
US dollars) deposited by my late client how have the same last name
with you from the same country.I shall send you more information and
procedures when I receive a positive response from you.
I look forward to hearing from you.
Yours sincerely,
Mr Robert Koffi
^ permalink raw reply
* Re: Fwd: DA850-evm MAC Address is random
From: Sekhar Nori @ 2017-08-29 11:42 UTC (permalink / raw)
To: Adam Ford; +Cc: Tony Lindgren, Grygorii Strashko, linux-omap, netdev
In-Reply-To: <CAHCN7x+-wymsqw96mt7Du=Huxh5rq=Rj9GidWPLXptJSW7taEA@mail.gmail.com>
On Tuesday 29 August 2017 03:53 PM, Adam Ford wrote:
> On Tue, Aug 29, 2017 at 3:23 AM, Sekhar Nori <nsekhar@ti.com> wrote:
>> On Tuesday 29 August 2017 02:42 AM, Tony Lindgren wrote:
>>> * Adam Ford <aford173@gmail.com> [170828 13:33]:
>>>> On Mon, Aug 28, 2017 at 1:54 PM, Grygorii Strashko
>>>> <grygorii.strashko@ti.com> wrote:
>>>>> Cc: Sekhar
>>>>>
>>>>> On 08/28/2017 10:32 AM, Adam Ford wrote:
>>>>>>
>>>>>> The davinvi_emac MAC address seems to attempt a call to
>>>>>> ti_cm_get_macid in cpsw-common.c but it returns the message
>>>>>> 'davinci_emac davinci_emac.1: incompatible machine/device type for
>>>>>> reading mac address ' and then generates a random MAC address.
>>>>>>
>>>>>> The function appears to lookup varions boards using
>>>>>> 'of_machine_is_compaible' and supports dm8148, am33xx, am3517, dm816,
>>>>>> am4372 and dra7. I don't see the ti,davinci-dm6467-emac which is
>>>>>> what's shown in the da850 device tree.
>>>>>>
>>>>>> Is there a patch somewhere for supporting the da850-evm?
>>>>>
>>>>>
>>>>> Not sure if MAC address can be read from Control module.
>>>>> May be Sekhar can say more?
>>>>
>>>> My understanding is that the MAC address is programmed by Logic PD
>>>> into the SPI flash. The Bootloader reads this from either SPI or its
>>>> env variables. Looking at the partition info listed in the
>>>> da850-evm.dts file, it appears as if they've reserved space for it.
>>>> Unfortunately, I don't see any code that reads it out. I was hoping
>>
>> This code is present in U-Boot sources at
>> board/davinci/da8xxevm/da850evm.c. See the function get_mac_addr() and
>> its usage in misc_init_r().
>>
>>>> there might be a way to just pass cmdline parameter from the
>>>> bootloader to the kernel to accept the MAC address.
>>>>
>>>>>
>>>>>>
>>>>>> If not, is there a way to pass the MAC address from U-Boot to the
>>>>>> driver so it doesn't generate a random MAC?
>>>>>
>>>>>
>>>>> "local-mac-address" dt porp
>>>>
>>>> The downside here, is that we'd have to have the Bootloader modify the
>>>> device tree.
>>>
>>> That piece of code exists somewhere in u-boot already. Note how
>>
>> Yes, it is fdt_fixup_ethernet() and its usage is in common/image-fdt.c.
>>
>>> we are populating the mac address for USB Ethernet drivers in
>>> u-boot and then the Ethernet driver code parses it. See commit
>>> 055d31de7158 ("ARM: omap3: beagleboard-xm: dt: Add ethernet to
>>> the device tree") for some more information.
>>>
>>> I think u-boot needs the ethernet alias for finding the interface.
>>
>> That's exactly what was missing. I have sent a patch for fixing that and
>> copied you there.
>
> Thanks for doing that.
>
>>
>> Adam, if I can get your Tested-by, I will make an attempt to send it for
>> v4.13 itself.
>
> I will test it. Do need to run some instruction or do something
> special in U-Boot to pass this in the proper place for the kernel to
> pull it? Tony's patch reference showed
> command for fdt set, but I am not sure I fully understand the
> parameters that went along with that.
Nope, just applying the patch and booting the with the new dtb should
result in the random mac address going away.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] staging: r8822be: Fix typo for CONFIG_RTLWIFI_DEBUG
From: Andreas Ziegler @ 2017-08-29 11:30 UTC (permalink / raw)
To: Greg KH
Cc: devel, Yan-Hsuan Chuang, Birming Chiu, netdev, Andreas Ziegler,
Steven Ting, Larry Finger
In-Reply-To: <20170829112643.GA14571@kroah.com>
The debugging output in deinit_priv is guarded by an #ifdef using
CONFIG_RTL_DEBUG. This symbol does not exist and should be
CONFIG_RTLWIFI_DEBUG instead.
Signed-off-by: Andreas Ziegler <andreas.ziegler@fau.de>
---
drivers/staging/rtlwifi/halmac/rtl_halmac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtlwifi/halmac/rtl_halmac.c b/drivers/staging/rtlwifi/halmac/rtl_halmac.c
index 031bf2c..888ca43 100644
--- a/drivers/staging/rtlwifi/halmac/rtl_halmac.c
+++ b/drivers/staging/rtlwifi/halmac/rtl_halmac.c
@@ -386,7 +386,7 @@ static void deinit_priv(struct rtl_halmac *halmac)
u32 count, size;
count = HALMAC_FEATURE_ALL + 1;
-#ifdef CONFIG_RTL_DEBUG
+#ifdef CONFIG_RTLWIFI_DEBUG
{
struct submit_ctx *sctx;
u32 i;
@@ -405,7 +405,7 @@ static void deinit_priv(struct rtl_halmac *halmac)
rtl_mfree((u8 *)sctx, sizeof(*sctx));
}
}
-#endif /* !CONFIG_RTL_DEBUG */
+#endif /* !CONFIG_RTLWIFI_DEBUG */
size = sizeof(*indicator) * count;
kfree((u8 *)indicator);
}
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 2/2] addrlabel: add/delete/get can run without rtnl
From: Florian Westphal @ 2017-08-29 11:29 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
In-Reply-To: <20170829112942.4791-1-fw@strlen.de>
There appears to be no need to use rtnl, addrlabel entries are refcounted
and add/delete is serialized by the addrlabel table spinlock.
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/ipv6/addrlabel.c | 22 +++++++++++++++++-----
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/net/ipv6/addrlabel.c b/net/ipv6/addrlabel.c
index cea5eb488013..b055bc79f56d 100644
--- a/net/ipv6/addrlabel.c
+++ b/net/ipv6/addrlabel.c
@@ -405,6 +405,18 @@ static const struct nla_policy ifal_policy[IFAL_MAX+1] = {
[IFAL_LABEL] = { .len = sizeof(u32), },
};
+static bool addrlbl_ifindex_exists(struct net *net, int ifindex)
+{
+
+ struct net_device *dev;
+
+ rcu_read_lock();
+ dev = dev_get_by_index_rcu(net, ifindex);
+ rcu_read_unlock();
+
+ return dev != NULL;
+}
+
static int ip6addrlbl_newdel(struct sk_buff *skb, struct nlmsghdr *nlh,
struct netlink_ext_ack *extack)
{
@@ -439,7 +451,7 @@ static int ip6addrlbl_newdel(struct sk_buff *skb, struct nlmsghdr *nlh,
switch (nlh->nlmsg_type) {
case RTM_NEWADDRLABEL:
if (ifal->ifal_index &&
- !__dev_get_by_index(net, ifal->ifal_index))
+ !addrlbl_ifindex_exists(net, ifal->ifal_index))
return -EINVAL;
err = ip6addrlbl_add(net, pfx, ifal->ifal_prefixlen,
@@ -548,7 +560,7 @@ static int ip6addrlbl_get(struct sk_buff *in_skb, struct nlmsghdr *nlh,
return -EINVAL;
if (ifal->ifal_index &&
- !__dev_get_by_index(net, ifal->ifal_index))
+ !addrlbl_ifindex_exists(net, ifal->ifal_index))
return -EINVAL;
if (!tb[IFAL_ADDRESS])
@@ -593,10 +605,10 @@ static int ip6addrlbl_get(struct sk_buff *in_skb, struct nlmsghdr *nlh,
void __init ipv6_addr_label_rtnl_register(void)
{
__rtnl_register(PF_INET6, RTM_NEWADDRLABEL, ip6addrlbl_newdel,
- NULL, 0);
+ NULL, RTNL_FLAG_DOIT_UNLOCKED);
__rtnl_register(PF_INET6, RTM_DELADDRLABEL, ip6addrlbl_newdel,
- NULL, 0);
+ NULL, RTNL_FLAG_DOIT_UNLOCKED);
__rtnl_register(PF_INET6, RTM_GETADDRLABEL, ip6addrlbl_get,
- ip6addrlbl_dump, 0);
+ ip6addrlbl_dump, RTNL_FLAG_DOIT_UNLOCKED);
}
--
2.13.0
^ permalink raw reply related
* [PATCH net-next 1/2] selftests: add addrlabel add/delete to rtnetlink.sh
From: Florian Westphal @ 2017-08-29 11:29 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
In-Reply-To: <20170829112942.4791-1-fw@strlen.de>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
tools/testing/selftests/net/rtnetlink.sh | 41 ++++++++++++++++++++++++++++++++
1 file changed, 41 insertions(+)
diff --git a/tools/testing/selftests/net/rtnetlink.sh b/tools/testing/selftests/net/rtnetlink.sh
index 84b4acf5baa9..57b5ff576240 100755
--- a/tools/testing/selftests/net/rtnetlink.sh
+++ b/tools/testing/selftests/net/rtnetlink.sh
@@ -195,6 +195,46 @@ kci_test_route_get()
echo "PASS: route get"
}
+kci_test_addrlabel()
+{
+ ret=0
+
+ ip addrlabel add prefix dead::/64 dev lo label 1
+ check_err $?
+
+ ip addrlabel list |grep -q "prefix dead::/64 dev lo label 1"
+ check_err $?
+
+ ip addrlabel del prefix dead::/64 dev lo label 1 2> /dev/null
+ check_err $?
+
+ ip addrlabel add prefix dead::/64 label 1 2> /dev/null
+ check_err $?
+
+ ip addrlabel del prefix dead::/64 label 1 2> /dev/null
+ check_err $?
+
+ # concurrent add/delete
+ for i in $(seq 1 1000); do
+ ip addrlabel add prefix 1c3::/64 label 12345 2>/dev/null
+ done &
+
+ for i in $(seq 1 1000); do
+ ip addrlabel del prefix 1c3::/64 label 12345 2>/dev/null
+ done
+
+ wait
+
+ ip addrlabel del prefix 1c3::/64 label 12345 2>/dev/null
+
+ if [ $ret -ne 0 ];then
+ echo "FAIL: ipv6 addrlabel"
+ return 1
+ fi
+
+ echo "PASS: ipv6 addrlabel"
+}
+
kci_test_rtnl()
{
kci_add_dummy
@@ -208,6 +248,7 @@ kci_test_rtnl()
kci_test_tc
kci_test_gre
kci_test_bridge
+ kci_test_addrlabel
kci_del_dummy
}
--
2.13.0
^ permalink raw reply related
* [PATCH net-next 0/2] addrlabel: don't use rtnl locking
From: Florian Westphal @ 2017-08-29 11:29 UTC (permalink / raw)
To: netdev
addrlabel doesn't appear to require rtnl lock as the addrlabel
table uses a spinlock to serialize add/delete operations.
Also, entries are reference counted so it should be safe
to call the rtnl ops without the rtnl mutex.
^ permalink raw reply
* Re: [PATCH 0/4] irda: move it to drivers/staging so we can delete it
From: Greg Kroah-Hartman @ 2017-08-29 11:28 UTC (permalink / raw)
To: Stefano Brivio
Cc: Geert Uytterhoeven, driverdevel, Samuel Ortiz,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
David S. Miller
In-Reply-To: <20170829131131.6e11c8f9@elisabeth>
On Tue, Aug 29, 2017 at 01:11:31PM +0200, Stefano Brivio wrote:
> On Tue, 29 Aug 2017 12:59:00 +0200
> Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> > Hi Greg,
> >
> > On Sun, Aug 27, 2017 at 5:03 PM, Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > > The IRDA code has long been obsolete and broken. So, to keep people
> > > from trying to use it, and to prevent people from having to maintain it,
> > > let's move it to drivers/staging/ so that we can delete it entirely from
> > > the kernel in a few releases.
> >
> > (diving into an early boot crash)
> >
> > Have you tried running this? ;-)
> >
> > irda_init() and net_dev_init() are both subsys_initcall()s.
> > But the former now runs before the latter, leading to:
> >
> > Unable to handle kernel NULL pointer dereference at virtual address 00000004
>
> Should be fixed by https://patchwork.ozlabs.org/patch/807006/
> ("[net-next] staging: irda: force to be a kernel module") I guess...
Yup, that's the fix for this issue.
Geert, does that fix the problem for you?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH net-next v3 01/13] phy: add sgmii and 10gkr modes to the phy_mode enum
From: Antoine Tenart @ 2017-08-29 11:27 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Antoine Tenart, davem, andrew, jason, sebastian.hesselbarth,
gregory.clement, thomas.petazzoni, nadavh, linux, linux-kernel,
mw, stefanc, miquel.raynal, netdev
In-Reply-To: <4c66e79f-d385-3cf5-6f24-2a4aec9fb3b4@ti.com>
[-- Attachment #1: Type: text/plain, Size: 722 bytes --]
Hi Kishon,
On Tue, Aug 29, 2017 at 04:08:29PM +0530, Kishon Vijay Abraham I wrote:
> On Monday 28 August 2017 08:27 PM, Antoine Tenart wrote:
> > This patch adds more generic PHY modes to the phy_mode enum, to
> > allow configuring generic PHYs to the SGMII and/or the 10GKR mode
> > by using the set_mode callback.
> >
> > Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
>
> Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Does this means the generic PHY patches of this series can go through
the net-next tree (once all the comments are taken into account)?
Thanks!
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: staging: r8822be: Add code for halmac sub-driver
From: Greg KH @ 2017-08-29 11:26 UTC (permalink / raw)
To: Andreas Ziegler
Cc: devel, Yan-Hsuan Chuang, Birming Chiu, netdev, Steven Ting,
Larry Finger
In-Reply-To: <0758af1e-f8d5-97be-8308-ba5535ab9415@fau.de>
On Tue, Aug 29, 2017 at 12:59:27PM +0200, Andreas Ziegler wrote:
> Hi Ping-Ke, hi Larry,
>
> I noticed your commit in linux-next today using the in-tree script at
> scripts/checkkconfigsymbols.py [0]. The script showed that it uses
> CONFIG_RTL_DEBUG in an #ifdef statement - this symbol, however, does not exist,
> and should probably be CONFIG_RTLWIFI_DEBUG instead.
>
> I attached a patch which fixes this problem.
Please resend this in a format in which I can apply it in (i.e. in a
proper email, cc: the correct mailing lists, etc.)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH net-next v3 02/13] phy: add the mvebu cp110 comphy driver
From: Antoine Tenart @ 2017-08-29 11:23 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Antoine Tenart, davem, andrew, jason, sebastian.hesselbarth,
gregory.clement, thomas.petazzoni, nadavh, linux, linux-kernel,
mw, stefanc, miquel.raynal, netdev
In-Reply-To: <50072fdd-d370-8518-a9f4-73e121114e67@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2724 bytes --]
Hi Kishon,
On Tue, Aug 29, 2017 at 04:34:17PM +0530, Kishon Vijay Abraham I wrote:
> On Monday 28 August 2017 08:27 PM, Antoine Tenart wrote:
> >
> > +config PHY_MVEBU_CP110_COMPHY
> > + tristate "Marvell CP110 comphy driver"
> > + depends on ARCH_MVEBU && OF
>
> (ARCH_MVEBU || COMPILE_TEST) above..
Sure, I'll update.
> > +static const struct mvebu_comhy_conf mvebu_comphy_cp110_modes[] = {
> > + /* lane 0 */
> > + MVEBU_COMPHY_CONF(0, 1, PHY_MODE_SGMII, 0x1),
> > + /* lane 1 */
> > + MVEBU_COMPHY_CONF(1, 2, PHY_MODE_SGMII, 0x1),
> > + /* lane 2 */
> > + MVEBU_COMPHY_CONF(2, 0, PHY_MODE_SGMII, 0x1),
> > + MVEBU_COMPHY_CONF(2, 0, PHY_MODE_10GKR, 0x1),
> > + /* lane 3 */
> > + MVEBU_COMPHY_CONF(3, 1, PHY_MODE_SGMII, 0x2),
> > + /* lane 4 */
> > + MVEBU_COMPHY_CONF(4, 0, PHY_MODE_SGMII, 0x2),
> > + MVEBU_COMPHY_CONF(4, 0, PHY_MODE_10GKR, 0x2),
> > + MVEBU_COMPHY_CONF(4, 1, PHY_MODE_SGMII, 0x1),
> > + /* lane 5 */
> > + MVEBU_COMPHY_CONF(5, 2, PHY_MODE_SGMII, 0x1),
> > +};
>
> IMHO all the lane and mode configuration should come from dt. That would make
> it more reusable when comphy is configured differently.
These connexions between engines and the comphy lanes are inside the
SoC. They won't change for a given SoC, and the actual configuration is
at the board level to know what is connected to the output of a given
lane, which is already described into the dt (the lane phandle).
So I think we can keep this inside the driver, and we'll had other
tables if the same comphy is ever used in another SoC.
What do you think?
> > +static const struct phy_ops mvebu_comphy_ops = {
> > + .power_on = mvebu_comphy_power_on,
> > + .power_off = mvebu_comphy_power_off,
> > + .set_mode = mvebu_comphy_set_mode,
>
> missing .owner
I'll fix that.
> > +static struct phy *mvebu_comphy_xlate(struct device *dev,
> > + struct of_phandle_args *args)
> > +{
> > + struct mvebu_comphy_priv *priv = dev_get_drvdata(dev);
> > + struct mvebu_comphy_lane *lane;
> > + int i;
> > +
> > + if (WARN_ON(args->args[0] >= MVEBU_COMPHY_PORTS))
> > + return ERR_PTR(-EINVAL);
> > +
> > + for (i = 0; i < MVEBU_COMPHY_LANES; i++) {
> > + if (!priv->phys[i])
> > + continue;
> > +
> > + lane = phy_get_drvdata(priv->phys[i]);
> > + if (priv->phys[i] && args->np == lane->of_node)
> > + break;
> > + }
>
> You should be able to directly use of_phy_simple_xlate to get the phy pointer.
> (For that to work child node pointer should be passed in devm_phy_create).
Good idea, I'll look into this and update.
Thanks!
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* RE: [PATCH v2 0/2] enable hires timer to timeout datagram socket
From: David Laight @ 2017-08-29 11:16 UTC (permalink / raw)
To: 'Vallish Vaidyeshwara', David Miller
Cc: shuah@kernel.org, richardcochran@gmail.com,
xiyou.wangcong@gmail.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, eduval@amazon.com,
anchalag@amazon.com
In-Reply-To: <20170827204725.GA8625@amazon.com>
From: Vallish Vaidyeshwara
> Sent: 27 August 2017 21:47
...
> I respect the decision not to upstream this patch series, however I
> wanted to provide additional details. Application wanting high
> resolution events with real guarantees is not the case, but the case
> here is regression in system call behavior:
>
> 1) Change in system call behavior:
> strace from 4.4 test run of waiting for 180 seconds on datagram socket:
> 10:25:48.239685 setsockopt(3, SOL_SOCKET, SO_RCVTIMEO, "\264\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 16) = 0
> 10:25:48.239755 recvmsg(3, 0x7ffd0a3beec0, 0) = -1 EAGAIN (Resource temporarily unavailable)
> 10:28:48.236989 fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
IMHO you should be complaining to the main kernel group who 'broke' the
timer code, not the networking group.
David
^ permalink raw reply
* Re: [PATCH 0/4] irda: move it to drivers/staging so we can delete it
From: Stefano Brivio @ 2017-08-29 11:11 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: driverdevel, Samuel Ortiz, Greg Kroah-Hartman,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
David S. Miller
In-Reply-To: <CAMuHMdUefXtqv9bFfgrkbu8NZRXeTD6qR-nErf6TCDz4L+OAWw@mail.gmail.com>
On Tue, 29 Aug 2017 12:59:00 +0200
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Greg,
>
> On Sun, Aug 27, 2017 at 5:03 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > The IRDA code has long been obsolete and broken. So, to keep people
> > from trying to use it, and to prevent people from having to maintain it,
> > let's move it to drivers/staging/ so that we can delete it entirely from
> > the kernel in a few releases.
>
> (diving into an early boot crash)
>
> Have you tried running this? ;-)
>
> irda_init() and net_dev_init() are both subsys_initcall()s.
> But the former now runs before the latter, leading to:
>
> Unable to handle kernel NULL pointer dereference at virtual address 00000004
Should be fixed by https://patchwork.ozlabs.org/patch/807006/
("[net-next] staging: irda: force to be a kernel module") I guess...
--
Stefano
^ permalink raw reply
* Re: staging: r8822be: Add code for halmac sub-driver
From: Andreas Ziegler @ 2017-08-29 10:59 UTC (permalink / raw)
To: Ping-Ke Shih, Larry Finger
Cc: gregkh, Yan-Hsuan Chuang, Birming Chiu, Shaofu, Steven Ting,
netdev, devel
In-Reply-To: <20170817174652.17656-5-Larry.Finger@lwfinger.net>
[-- Attachment #1.1: Type: text/plain, Size: 482 bytes --]
Hi Ping-Ke, hi Larry,
I noticed your commit in linux-next today using the in-tree script at
scripts/checkkconfigsymbols.py [0]. The script showed that it uses
CONFIG_RTL_DEBUG in an #ifdef statement - this symbol, however, does not exist,
and should probably be CONFIG_RTLWIFI_DEBUG instead.
I attached a patch which fixes this problem.
Best regards,
Andreas Ziegler
[0]: I called the script like this: './scripts/checkkconfigsymbols.py --force -c
938a0447f094'
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-staging-r8822be-Fix-typo-for-CONFIG_RTLWIFI_DEBUG.patch --]
[-- Type: text/x-patch; name="0001-staging-r8822be-Fix-typo-for-CONFIG_RTLWIFI_DEBUG.patch", Size: 1319 bytes --]
From 6c713900ed877c01f94fb76630f9ffd32c73ec88 Mon Sep 17 00:00:00 2001
From: Andreas Ziegler <andreas.ziegler@fau.de>
Date: Tue, 29 Aug 2017 12:50:37 +0200
Subject: [PATCH] staging: r8822be: Fix typo for CONFIG_RTLWIFI_DEBUG
The debugging output in deinit_priv is guarded by an #ifdef using
CONFIG_RTL_DEBUG. This symbol does not exist and should be
CONFIG_RTLWIFI_DEBUG instead.
Signed-off-by: Andreas Ziegler <andreas.ziegler@fau.de>
---
drivers/staging/rtlwifi/halmac/rtl_halmac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtlwifi/halmac/rtl_halmac.c b/drivers/staging/rtlwifi/halmac/rtl_halmac.c
index 031bf2c..888ca43 100644
--- a/drivers/staging/rtlwifi/halmac/rtl_halmac.c
+++ b/drivers/staging/rtlwifi/halmac/rtl_halmac.c
@@ -386,7 +386,7 @@ static void deinit_priv(struct rtl_halmac *halmac)
u32 count, size;
count = HALMAC_FEATURE_ALL + 1;
-#ifdef CONFIG_RTL_DEBUG
+#ifdef CONFIG_RTLWIFI_DEBUG
{
struct submit_ctx *sctx;
u32 i;
@@ -405,7 +405,7 @@ static void deinit_priv(struct rtl_halmac *halmac)
rtl_mfree((u8 *)sctx, sizeof(*sctx));
}
}
-#endif /* !CONFIG_RTL_DEBUG */
+#endif /* !CONFIG_RTLWIFI_DEBUG */
size = sizeof(*indicator) * count;
kfree((u8 *)indicator);
}
--
2.7.4
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5450 bytes --]
^ 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