* [PATCH v2 net 2/4] tls: Fix write space handling
From: Boris Pismenny @ 2019-02-27 15:38 UTC (permalink / raw)
To: aviadye, davejwatson, john.fastabend, daniel, vakul.garg, netdev
Cc: eranbe, borisp
In-Reply-To: <20190227153806.17080-1-borisp@mellanox.com>
TLS device cannot use the sw context. This patch returns the original
tls device write space handler and moves the sw/device specific portions
to the relevant files.
Also, we remove the write_space call for the tls_sw flow, because it
handles partial records in its delayed tx work handler.
Fixes: a42055e8d2c3 ("net/tls: Add support for async encryption of records for performance")
Signed-off-by: Boris Pismenny <borisp@mellanox.com>
Reviewed-by: Eran Ben Elisha <eranbe@mellanox.com>
---
include/net/tls.h | 3 +++
net/tls/tls_device.c | 17 +++++++++++++++++
net/tls/tls_main.c | 15 ++++++---------
net/tls/tls_sw.c | 13 +++++++++++++
4 files changed, 39 insertions(+), 9 deletions(-)
diff --git a/include/net/tls.h b/include/net/tls.h
index a528a082da73..a5a938583295 100644
--- a/include/net/tls.h
+++ b/include/net/tls.h
@@ -519,6 +519,9 @@ static inline bool tls_sw_has_ctx_tx(const struct sock *sk)
return !!tls_sw_ctx_tx(ctx);
}
+void tls_sw_write_space(struct sock *sk, struct tls_context *ctx);
+void tls_device_write_space(struct sock *sk, struct tls_context *ctx);
+
static inline struct tls_offload_context_rx *
tls_offload_ctx_rx(const struct tls_context *tls_ctx)
{
diff --git a/net/tls/tls_device.c b/net/tls/tls_device.c
index 3e5e8e021a87..4a1da837a733 100644
--- a/net/tls/tls_device.c
+++ b/net/tls/tls_device.c
@@ -546,6 +546,23 @@ static int tls_device_push_pending_record(struct sock *sk, int flags)
return tls_push_data(sk, &msg_iter, 0, flags, TLS_RECORD_TYPE_DATA);
}
+void tls_device_write_space(struct sock *sk, struct tls_context *ctx)
+{
+ int rc = 0;
+
+ if (!sk->sk_write_pending && tls_is_partially_sent_record(ctx)) {
+ gfp_t sk_allocation = sk->sk_allocation;
+
+ sk->sk_allocation = GFP_ATOMIC;
+ rc = tls_push_partial_record(sk, ctx,
+ MSG_DONTWAIT | MSG_NOSIGNAL);
+ sk->sk_allocation = sk_allocation;
+ }
+
+ if (!rc)
+ ctx->sk_write_space(sk);
+}
+
void handle_device_resync(struct sock *sk, u32 seq, u64 rcd_sn)
{
struct tls_context *tls_ctx = tls_get_ctx(sk);
diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c
index 7e05af75536d..17e8667917aa 100644
--- a/net/tls/tls_main.c
+++ b/net/tls/tls_main.c
@@ -212,7 +212,6 @@ int tls_push_partial_record(struct sock *sk, struct tls_context *ctx,
static void tls_write_space(struct sock *sk)
{
struct tls_context *ctx = tls_get_ctx(sk);
- struct tls_sw_context_tx *tx_ctx = tls_sw_ctx_tx(ctx);
/* If in_tcp_sendpages call lower protocol write space handler
* to ensure we wake up any waiting operations there. For example
@@ -223,14 +222,12 @@ static void tls_write_space(struct sock *sk)
return;
}
- /* Schedule the transmission if tx list is ready */
- if (is_tx_ready(tx_ctx) && !sk->sk_write_pending) {
- /* Schedule the transmission */
- if (!test_and_set_bit(BIT_TX_SCHEDULED, &tx_ctx->tx_bitmask))
- schedule_delayed_work(&tx_ctx->tx_work.work, 0);
- }
-
- ctx->sk_write_space(sk);
+#ifdef CONFIG_TLS_DEVICE
+ if (ctx->tx_conf == TLS_HW)
+ tls_device_write_space(sk, ctx);
+ else
+#endif
+ tls_sw_write_space(sk, ctx);
}
static void tls_ctx_free(struct tls_context *ctx)
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index 1cc830582fa8..917caacd4d31 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -2126,6 +2126,19 @@ static void tx_work_handler(struct work_struct *work)
release_sock(sk);
}
+void tls_sw_write_space(struct sock *sk, struct tls_context *ctx)
+{
+ struct tls_sw_context_tx *tx_ctx = tls_sw_ctx_tx(ctx);
+
+ /* Schedule the transmission if tx list is ready */
+ if (is_tx_ready(tx_ctx) && !sk->sk_write_pending) {
+ /* Schedule the transmission */
+ if (!test_and_set_bit(BIT_TX_SCHEDULED,
+ &tx_ctx->tx_bitmask))
+ schedule_delayed_work(&tx_ctx->tx_work.work, 0);
+ }
+}
+
int tls_set_sw_offload(struct sock *sk, struct tls_context *ctx, int tx)
{
struct tls_context *tls_ctx = tls_get_ctx(sk);
--
2.12.2
^ permalink raw reply related
* [PATCH v2 net 1/4] tls: Fix tls_device handling of partial records
From: Boris Pismenny @ 2019-02-27 15:38 UTC (permalink / raw)
To: aviadye, davejwatson, john.fastabend, daniel, vakul.garg, netdev
Cc: eranbe, borisp
In-Reply-To: <20190227153806.17080-1-borisp@mellanox.com>
Cleanup the handling of partial records while fixing a bug where the
tls_push_pending_closed_record function is using the software tls
context instead of the hardware context.
The bug resulted in the following crash:
[ 88.791229] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
[ 88.793271] #PF error: [normal kernel read fault]
[ 88.794449] PGD 800000022a426067 P4D 800000022a426067 PUD 22a156067 PMD 0
[ 88.795958] Oops: 0000 [#1] SMP PTI
[ 88.796884] CPU: 2 PID: 4973 Comm: openssl Not tainted 5.0.0-rc4+ #3
[ 88.798314] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
[ 88.800067] RIP: 0010:tls_tx_records+0xef/0x1d0 [tls]
[ 88.801256] Code: 00 02 48 89 43 08 e8 a0 0b 96 d9 48 89 df e8 48 dd
4d d9 4c 89 f8 4d 8b bf 98 00 00 00 48 05 98 00 00 00 48 89 04 24 49 39
c7 <49> 8b 1f 4d 89 fd 0f 84 af 00 00 00 41 8b 47 10 85 c0 0f 85 8d 00
[ 88.805179] RSP: 0018:ffffbd888186fca8 EFLAGS: 00010213
[ 88.806458] RAX: ffff9af1ed657c98 RBX: ffff9af1e88a1980 RCX: 0000000000000000
[ 88.808050] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9af1e88a1980
[ 88.809724] RBP: ffff9af1e88a1980 R08: 0000000000000017 R09: ffff9af1ebeeb700
[ 88.811294] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
[ 88.812917] R13: ffff9af1e88a1980 R14: ffff9af1ec13f800 R15: 0000000000000000
[ 88.814506] FS: 00007fcad2240740(0000) GS:ffff9af1f7880000(0000) knlGS:0000000000000000
[ 88.816337] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 88.817717] CR2: 0000000000000000 CR3: 0000000228b3e000 CR4: 00000000001406e0
[ 88.819328] Call Trace:
[ 88.820123] tls_push_data+0x628/0x6a0 [tls]
[ 88.821283] ? remove_wait_queue+0x20/0x60
[ 88.822383] ? n_tty_read+0x683/0x910
[ 88.823363] tls_device_sendmsg+0x53/0xa0 [tls]
[ 88.824505] sock_sendmsg+0x36/0x50
[ 88.825492] sock_write_iter+0x87/0x100
[ 88.826521] __vfs_write+0x127/0x1b0
[ 88.827499] vfs_write+0xad/0x1b0
[ 88.828454] ksys_write+0x52/0xc0
[ 88.829378] do_syscall_64+0x5b/0x180
[ 88.830369] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 88.831603] RIP: 0033:0x7fcad1451680
[ 1248.470626] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
[ 1248.472564] #PF error: [normal kernel read fault]
[ 1248.473790] PGD 0 P4D 0
[ 1248.474642] Oops: 0000 [#1] SMP PTI
[ 1248.475651] CPU: 3 PID: 7197 Comm: openssl Tainted: G OE 5.0.0-rc4+ #3
[ 1248.477426] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
[ 1248.479310] RIP: 0010:tls_tx_records+0x110/0x1f0 [tls]
[ 1248.480644] Code: 00 02 48 89 43 08 e8 4f cb 63 d7 48 89 df e8 f7 9c
1b d7 4c 89 f8 4d 8b bf 98 00 00 00 48 05 98 00 00 00 48 89 04 24 49 39
c7 <49> 8b 1f 4d 89 fd 0f 84 af 00 00 00 41 8b 47 10 85 c0 0f 85 8d 00
[ 1248.484825] RSP: 0018:ffffaa0a41543c08 EFLAGS: 00010213
[ 1248.486154] RAX: ffff955a2755dc98 RBX: ffff955a36031980 RCX: 0000000000000006
[ 1248.487855] RDX: 0000000000000000 RSI: 000000000000002b RDI: 0000000000000286
[ 1248.489524] RBP: ffff955a36031980 R08: 0000000000000000 R09: 00000000000002b1
[ 1248.491394] R10: 0000000000000003 R11: 00000000ad55ad55 R12: 0000000000000000
[ 1248.493162] R13: 0000000000000000 R14: ffff955a2abe6c00 R15: 0000000000000000
[ 1248.494923] FS: 0000000000000000(0000) GS:ffff955a378c0000(0000) knlGS:0000000000000000
[ 1248.496847] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1248.498357] CR2: 0000000000000000 CR3: 000000020c40e000 CR4: 00000000001406e0
[ 1248.500136] Call Trace:
[ 1248.500998] ? tcp_check_oom+0xd0/0xd0
[ 1248.502106] tls_sk_proto_close+0x127/0x1e0 [tls]
[ 1248.503411] inet_release+0x3c/0x60
[ 1248.504530] __sock_release+0x3d/0xb0
[ 1248.505611] sock_close+0x11/0x20
[ 1248.506612] __fput+0xb4/0x220
[ 1248.507559] task_work_run+0x88/0xa0
[ 1248.508617] do_exit+0x2cb/0xbc0
[ 1248.509597] ? core_sys_select+0x17a/0x280
[ 1248.510740] do_group_exit+0x39/0xb0
[ 1248.511789] get_signal+0x1d0/0x630
[ 1248.512823] do_signal+0x36/0x620
[ 1248.513822] exit_to_usermode_loop+0x5c/0xc6
[ 1248.515003] do_syscall_64+0x157/0x180
[ 1248.516094] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 1248.517456] RIP: 0033:0x7fb398bd3f53
[ 1248.518537] Code: Bad RIP value.
Fixes: a42055e8d2c3 ("net/tls: Add support for async encryption of records for performance")
Signed-off-by: Boris Pismenny <borisp@mellanox.com>
Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
---
include/net/tls.h | 20 ++++----------------
net/tls/tls_device.c | 9 +++++----
net/tls/tls_main.c | 13 -------------
3 files changed, 9 insertions(+), 33 deletions(-)
diff --git a/include/net/tls.h b/include/net/tls.h
index 9f4117ae2297..a528a082da73 100644
--- a/include/net/tls.h
+++ b/include/net/tls.h
@@ -199,10 +199,6 @@ struct tls_offload_context_tx {
(ALIGN(sizeof(struct tls_offload_context_tx), sizeof(void *)) + \
TLS_DRIVER_STATE_SIZE)
-enum {
- TLS_PENDING_CLOSED_RECORD
-};
-
struct cipher_context {
char *iv;
char *rec_seq;
@@ -335,17 +331,14 @@ int tls_push_sg(struct sock *sk, struct tls_context *ctx,
int tls_push_partial_record(struct sock *sk, struct tls_context *ctx,
int flags);
-int tls_push_pending_closed_record(struct sock *sk, struct tls_context *ctx,
- int flags, long *timeo);
-
static inline struct tls_msg *tls_msg(struct sk_buff *skb)
{
return (struct tls_msg *)strp_msg(skb);
}
-static inline bool tls_is_pending_closed_record(struct tls_context *ctx)
+static inline bool tls_is_partially_sent_record(struct tls_context *ctx)
{
- return test_bit(TLS_PENDING_CLOSED_RECORD, &ctx->flags);
+ return !!ctx->partially_sent_record;
}
static inline int tls_complete_pending_work(struct sock *sk,
@@ -357,17 +350,12 @@ static inline int tls_complete_pending_work(struct sock *sk,
if (unlikely(sk->sk_write_pending))
rc = wait_on_pending_writer(sk, timeo);
- if (!rc && tls_is_pending_closed_record(ctx))
- rc = tls_push_pending_closed_record(sk, ctx, flags, timeo);
+ if (!rc && tls_is_partially_sent_record(ctx))
+ rc = tls_push_partial_record(sk, ctx, flags);
return rc;
}
-static inline bool tls_is_partially_sent_record(struct tls_context *ctx)
-{
- return !!ctx->partially_sent_record;
-}
-
static inline bool tls_is_pending_open_record(struct tls_context *tls_ctx)
{
return tls_ctx->pending_open_record_frags;
diff --git a/net/tls/tls_device.c b/net/tls/tls_device.c
index a5c17c47d08a..3e5e8e021a87 100644
--- a/net/tls/tls_device.c
+++ b/net/tls/tls_device.c
@@ -271,7 +271,6 @@ static int tls_push_record(struct sock *sk,
list_add_tail(&record->list, &offload_ctx->records_list);
spin_unlock_irq(&offload_ctx->lock);
offload_ctx->open_record = NULL;
- set_bit(TLS_PENDING_CLOSED_RECORD, &ctx->flags);
tls_advance_record_sn(sk, &ctx->tx, ctx->crypto_send.info.version);
for (i = 0; i < record->num_frags; i++) {
@@ -368,9 +367,11 @@ static int tls_push_data(struct sock *sk,
return -sk->sk_err;
timeo = sock_sndtimeo(sk, flags & MSG_DONTWAIT);
- rc = tls_complete_pending_work(sk, tls_ctx, flags, &timeo);
- if (rc < 0)
- return rc;
+ if (tls_is_partially_sent_record(tls_ctx)) {
+ rc = tls_push_partial_record(sk, tls_ctx, flags);
+ if (rc < 0)
+ return rc;
+ }
pfrag = sk_page_frag(sk);
diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c
index caff15b2f9b2..7e05af75536d 100644
--- a/net/tls/tls_main.c
+++ b/net/tls/tls_main.c
@@ -209,19 +209,6 @@ int tls_push_partial_record(struct sock *sk, struct tls_context *ctx,
return tls_push_sg(sk, ctx, sg, offset, flags);
}
-int tls_push_pending_closed_record(struct sock *sk,
- struct tls_context *tls_ctx,
- int flags, long *timeo)
-{
- struct tls_sw_context_tx *ctx = tls_sw_ctx_tx(tls_ctx);
-
- if (tls_is_partially_sent_record(tls_ctx) ||
- !list_empty(&ctx->tx_list))
- return tls_tx_records(sk, flags);
- else
- return tls_ctx->push_pending_record(sk, flags);
-}
-
static void tls_write_space(struct sock *sk)
{
struct tls_context *ctx = tls_get_ctx(sk);
--
2.12.2
^ permalink raw reply related
* [PATCH v2 net 4/4] tls: Fix tls_device receive
From: Boris Pismenny @ 2019-02-27 15:38 UTC (permalink / raw)
To: aviadye, davejwatson, john.fastabend, daniel, vakul.garg, netdev
Cc: eranbe, borisp
In-Reply-To: <20190227153806.17080-1-borisp@mellanox.com>
Currently, the receive function fails to handle records already
decrypted by the device due to the commit mentioned below.
This commit advances the TLS record sequence number and prepares the context
to handle the next record.
Fixes: fedf201e1296 ("net: tls: Refactor control message handling on recv")
Signed-off-by: Boris Pismenny <borisp@mellanox.com>
Reviewed-by: Eran Ben Elisha <eranbe@mellanox.com>
---
net/tls/tls_sw.c | 25 ++++++++++++++-----------
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index 68cd026fa57c..425351ac2a9b 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -1467,23 +1467,26 @@ static int decrypt_skb_update(struct sock *sk, struct sk_buff *skb,
struct strp_msg *rxm = strp_msg(skb);
int err = 0;
+ if (!ctx->decrypted) {
#ifdef CONFIG_TLS_DEVICE
- err = tls_device_decrypted(sk, skb);
- if (err < 0)
- return err;
+ err = tls_device_decrypted(sk, skb);
+ if (err < 0)
+ return err;
#endif
- if (!ctx->decrypted) {
- err = decrypt_internal(sk, skb, dest, NULL, chunk, zc, async);
- if (err < 0) {
- if (err == -EINPROGRESS)
- tls_advance_record_sn(sk, &tls_ctx->rx,
- version);
+ /* Still not decrypted after tls_device */
+ if (!ctx->decrypted) {
+ err = decrypt_internal(sk, skb, dest, NULL, chunk, zc,
+ async);
+ if (err < 0) {
+ if (err == -EINPROGRESS)
+ tls_advance_record_sn(sk, &tls_ctx->rx,
+ version);
- return err;
+ return err;
+ }
}
rxm->full_len -= padding_length(ctx, tls_ctx, skb);
-
rxm->offset += prot->prepend_size;
rxm->full_len -= prot->overhead_size;
tls_advance_record_sn(sk, &tls_ctx->rx, version);
--
2.12.2
^ permalink raw reply related
* [PATCH v2 net 0/4] tls: Fix issues in tls_device
From: Boris Pismenny @ 2019-02-27 15:38 UTC (permalink / raw)
To: aviadye, davejwatson, john.fastabend, daniel, vakul.garg, netdev
Cc: eranbe, borisp
This series fixes issues encountered in tls_device code paths,
which were introduced recently.
Additionally, this series includes a fix for tls software only receive flow,
which causes corruption of payload received by user space applications.
This series was tested using the OpenSSL integration of KTLS -
https://github.com/mellan
Boris Pismenny (3):
tls: Fix tls_device handling of partial records
tls: Fix write space handling
tls: Fix tls_device receive
Eran Ben Elisha (1):
tls: Fix mixing between async capable and async
include/net/tls.h | 23 +++++++----------------
net/tls/tls_device.c | 26 ++++++++++++++++++++++----
net/tls/tls_main.c | 28 ++++++---------------------
net/tls/tls_sw.c | 53 +++++++++++++++++++++++++++++++++++-----------------
4 files changed, 71 insertions(+), 59 deletions(-)
--
2.12.2
^ permalink raw reply
* [PATCH v2 net 3/4] tls: Fix mixing between async capable and async
From: Boris Pismenny @ 2019-02-27 15:38 UTC (permalink / raw)
To: aviadye, davejwatson, john.fastabend, daniel, vakul.garg, netdev
Cc: eranbe, borisp
In-Reply-To: <20190227153806.17080-1-borisp@mellanox.com>
From: Eran Ben Elisha <eranbe@mellanox.com>
Today, tls_sw_recvmsg is capable of using asynchronous mode to handle
application data TLS records. Moreover, it assumes that if the cipher
can be handled asynchronously, then all packets will be processed
asynchronously.
However, this assumption is not always true. Specifically, for AES-GCM
in TLS1.2, it causes data corruption, and breaks user applications.
This patch fixes this problem by separating the async capability from
the decryption operation result.
Fixes: c0ab4732d4c6 ("net/tls: Do not use async crypto for non-data records")
Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
Reviewed-by: Boris Pismenny <borisp@mellanox.com>
---
net/tls/tls_sw.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index 917caacd4d31..68cd026fa57c 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -1693,7 +1693,8 @@ int tls_sw_recvmsg(struct sock *sk,
bool zc = false;
int to_decrypt;
int chunk = 0;
- bool async;
+ bool async_capable;
+ bool async = false;
skb = tls_wait_data(sk, psock, flags, timeo, &err);
if (!skb) {
@@ -1727,21 +1728,23 @@ int tls_sw_recvmsg(struct sock *sk,
/* Do not use async mode if record is non-data */
if (ctx->control == TLS_RECORD_TYPE_DATA)
- async = ctx->async_capable;
+ async_capable = ctx->async_capable;
else
- async = false;
+ async_capable = false;
err = decrypt_skb_update(sk, skb, &msg->msg_iter,
- &chunk, &zc, async);
+ &chunk, &zc, async_capable);
if (err < 0 && err != -EINPROGRESS) {
tls_err_abort(sk, EBADMSG);
goto recv_end;
}
- if (err == -EINPROGRESS)
+ if (err == -EINPROGRESS) {
+ async = true;
num_async++;
- else if (prot->version == TLS_1_3_VERSION)
+ } else if (prot->version == TLS_1_3_VERSION) {
tlm->control = ctx->control;
+ }
/* If the type of records being processed is not known yet,
* set it to record type just dequeued. If it is already known,
--
2.12.2
^ permalink raw reply related
* Re: [PATCH v2 3/6] sched/cpufreq: Annotate cpufreq_update_util_data pointer with __rcu
From: Joel Fernandes @ 2019-02-27 15:42 UTC (permalink / raw)
To: Paul E. McKenney
Cc: linux-kernel, Alexei Starovoitov, Christian Brauner,
Daniel Borkmann, David Ahern, David S. Miller, Ingo Molnar,
Jakub Kicinski, Jeff Kirsher, Jesper Dangaard Brouer,
John Fastabend, Josh Triplett, keescook, kernel-hardening,
kernel-team, Kirill Tkhai, Lai Jiangshan, Martin KaFai Lau,
Mathieu Desnoyers, netdev, Peter Zijlstra, Quentin Perret, rcu,
Song Liu, Steven Rostedt, Vincent Guittot, xdp-newbies,
Yonghong Song
In-Reply-To: <20190225211026.GX4072@linux.ibm.com>
On Mon, Feb 25, 2019 at 01:10:26PM -0800, Paul E. McKenney wrote:
> On Sat, Feb 23, 2019 at 01:34:31AM -0500, Joel Fernandes (Google) wrote:
> > Recently I added an RCU annotation check to rcu_assign_pointer(). All
> > pointers assigned to RCU protected data are to be annotated with __rcu
> > inorder to be able to use rcu_assign_pointer() similar to checks in
> > other RCU APIs.
> >
> > This resulted in a sparse error: kernel//sched/cpufreq.c:41:9: sparse:
> > error: incompatible types in comparison expression (different address
> > spaces)
> >
> > Fix this by annotating cpufreq_update_util_data pointer with __rcu. This
> > will also help sparse catch any future RCU misuage bugs.
> >
> > Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
>
> From an RCU perspective:
>
> Reviewed-by: Paul E. McKenney <paulmck@linux.ibm.com>
Thanks a lot Paul.
Peter, Rafael, Steve,
Are you Ok with the patches 3-6? It will be nice to quiet down sparse.
thanks,
- Joel
> > ---
> > kernel/sched/cpufreq.c | 2 +-
> > kernel/sched/sched.h | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/kernel/sched/cpufreq.c b/kernel/sched/cpufreq.c
> > index 22bd8980f32f..e316ee7bb2e5 100644
> > --- a/kernel/sched/cpufreq.c
> > +++ b/kernel/sched/cpufreq.c
> > @@ -7,7 +7,7 @@
> > */
> > #include "sched.h"
> >
> > -DEFINE_PER_CPU(struct update_util_data *, cpufreq_update_util_data);
> > +DEFINE_PER_CPU(struct update_util_data __rcu *, cpufreq_update_util_data);
> >
> > /**
> > * cpufreq_add_update_util_hook - Populate the CPU's update_util_data pointer.
> > diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> > index d04530bf251f..2ab545d40381 100644
> > --- a/kernel/sched/sched.h
> > +++ b/kernel/sched/sched.h
> > @@ -2166,7 +2166,7 @@ static inline u64 irq_time_read(int cpu)
> > #endif /* CONFIG_IRQ_TIME_ACCOUNTING */
> >
> > #ifdef CONFIG_CPU_FREQ
> > -DECLARE_PER_CPU(struct update_util_data *, cpufreq_update_util_data);
> > +DECLARE_PER_CPU(struct update_util_data __rcu *, cpufreq_update_util_data);
> >
> > /**
> > * cpufreq_update_util - Take a note about CPU utilization changes.
> > --
> > 2.21.0.rc0.258.g878e2cd30e-goog
> >
>
^ permalink raw reply
* Re: [PATCH] net: netem: fix skb length BUG_ON in __skb_to_sgvec
From: Eric Dumazet @ 2019-02-27 15:53 UTC (permalink / raw)
To: Sheng Lan, Eric Dumazet, Stephen Hemminger
Cc: davem, netdev, netem, xuhanbing, zhengshaoyu, jiqin.ji,
liuzhiqiang26, yuehaibing
In-Reply-To: <dd75923d-a079-7db0-6903-a31fff062d26@huawei.com>
On 02/27/2019 03:26 AM, Sheng Lan wrote:
>
> I traced again and found that the skb was not sent, master skb was still in write queue,
> because the function tcp_transmit_skb() returns 1 (NET_XMIT_DROP), thus it can be retransmit.
> I found the error value NET_XMIT_DROP returns from netem_enqueue(), when the length of qdisc queue
> is greater than queue limit value.
>
> In netem_enqueue() the skb is cloned before returning the NET_XMIT_DROP error value,
> thus the master skb is still in write queue and be cloned in netem_enqueue(). This may cause the master
> skb be retransmit and fragmented again while it is cloned.
>
> I think there are potential risks that tso_fragment() will get a cloned skb if skb is cloned by lower layer.
> I try to fix it by moving returning error value statment to the front of the skb_clone() in netem_enqueue(), and it works.
> And netem_enqueue() constructs corrupt packets statment returns NET_XMIT_DROP too. To fix this completely should I move the
> constructing corrupt statment to the front of the skb_clone() ?
> Please correct me if I am wrong, and I need your advice.
>
Hi
Choices are either :
1) netem sends a proper return value if a packet has been queued.
2) TCP (and probably other protocols) no longer trust lower stack
and always move the master skb in rtx queue,
even if the transmit of the (first) clone failed.
I prefer 1), since netem is not used in the fast path, generally...
diff --git a/net/sched/sch_netem.c b/net/sched/sch_netem.c
index 75046ec7214449c631c38eaab5e4a51644cfa0e5..f6ea2d44dffe328a2fd1a468e209aac0bfaccd49 100644
--- a/net/sched/sch_netem.c
+++ b/net/sched/sch_netem.c
@@ -447,6 +447,7 @@ static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch,
int nb = 0;
int count = 1;
int rc = NET_XMIT_SUCCESS;
+ int rc_drop = NET_XMIT_DROP;
/* Do not fool qdisc_drop_all() */
skb->prev = NULL;
@@ -486,6 +487,7 @@ static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch,
q->duplicate = 0;
rootq->enqueue(skb2, rootq, to_free);
q->duplicate = dupsave;
+ rc_drop = NET_XMIT_SUCCESS;
}
/*
@@ -498,7 +500,7 @@ static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch,
if (skb_is_gso(skb)) {
segs = netem_segment(skb, sch, to_free);
if (!segs)
- return NET_XMIT_DROP;
+ return rc_drop;
} else {
segs = skb;
}
@@ -521,9 +523,10 @@ static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch,
1<<(prandom_u32() % 8);
}
- if (unlikely(sch->q.qlen >= sch->limit))
- return qdisc_drop_all(skb, sch, to_free);
-
+ if (unlikely(sch->q.qlen >= sch->limit)) {
+ qdisc_drop_all(skb, sch, to_free);
+ return rc_drop;
+ }
qdisc_qstats_backlog_inc(sch, skb);
cb = netem_skb_cb(skb);
^ permalink raw reply related
* [PATCH bpf-next] bpf: add missing entries to bpf_helpers.h
From: Willem de Bruijn @ 2019-02-27 16:08 UTC (permalink / raw)
To: netdev; +Cc: ast, daniel, kafai, sdf, Willem de Bruijn
From: Willem de Bruijn <willemb@google.com>
This header defines the BPF functions enumerated in uapi/linux.bpf.h
in a callable format. Expand to include all registered functions.
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
changes pre->v1:
- add brief commit message
(not copying Acks as they do not necessarily agree with that)
- change return type from ull to uint for
bpf_get_cgroup_classid, bpf_get_route_realm, bpf_get_hash_recalc
- change size arg from int to __u32 for bpf_probe_read_str
---
tools/testing/selftests/bpf/bpf_helpers.h | 30 +++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/tools/testing/selftests/bpf/bpf_helpers.h b/tools/testing/selftests/bpf/bpf_helpers.h
index d9999f1ed1d2a..026bea831e039 100644
--- a/tools/testing/selftests/bpf/bpf_helpers.h
+++ b/tools/testing/selftests/bpf/bpf_helpers.h
@@ -232,6 +232,36 @@ static int (*bpf_skb_change_head)(void *, int len, int flags) =
(void *) BPF_FUNC_skb_change_head;
static int (*bpf_skb_pull_data)(void *, int len) =
(void *) BPF_FUNC_skb_pull_data;
+static unsigned int (*bpf_get_cgroup_classid)(void *ctx) =
+ (void *) BPF_FUNC_get_cgroup_classid;
+static unsigned int (*bpf_get_route_realm)(void *ctx) =
+ (void *) BPF_FUNC_get_route_realm;
+static int (*bpf_skb_change_proto)(void *ctx, __be16 proto, __u64 flags) =
+ (void *) BPF_FUNC_skb_change_proto;
+static int (*bpf_skb_change_type)(void *ctx, __u32 type) =
+ (void *) BPF_FUNC_skb_change_type;
+static unsigned int (*bpf_get_hash_recalc)(void *ctx) =
+ (void *) BPF_FUNC_get_hash_recalc;
+static unsigned long long (*bpf_get_current_task)(void *ctx) =
+ (void *) BPF_FUNC_get_current_task;
+static int (*bpf_skb_change_tail)(void *ctx, __u32 len, __u64 flags) =
+ (void *) BPF_FUNC_skb_change_tail;
+static long long (*bpf_csum_update)(void *ctx, __u32 csum) =
+ (void *) BPF_FUNC_csum_update;
+static void (*bpf_set_hash_invalid)(void *ctx) =
+ (void *) BPF_FUNC_set_hash_invalid;
+static int (*bpf_get_numa_node_id)(void) =
+ (void *) BPF_FUNC_get_numa_node_id;
+static int (*bpf_probe_read_str)(void *ctx, __u32 size,
+ const void *unsafe_ptr) =
+ (void *) BPF_FUNC_probe_read_str;
+static unsigned int (*bpf_get_socket_uid)(void *ctx) =
+ (void *) BPF_FUNC_get_socket_uid;
+static unsigned int (*bpf_set_hash)(void *ctx, __u32 hash) =
+ (void *) BPF_FUNC_set_hash;
+static int (*bpf_skb_adjust_room)(void *ctx, __s32 len_diff, __u32 mode,
+ unsigned long long flags) =
+ (void *) BPF_FUNC_skb_adjust_room;
/* Scan the ARCH passed in from ARCH env variable (see Makefile) */
#if defined(__TARGET_ARCH_x86)
--
2.21.0.rc2.261.ga7da99ff1b-goog
^ permalink raw reply related
* Re: [PATCH net-next] net: sched: pie: fix 64-bit division
From: Leslie Monis @ 2019-02-27 16:12 UTC (permalink / raw)
To: David Laight; +Cc: netdev
In-Reply-To: <44c1c447befd45e49a06b1e3d3f5f7a6@AcuMS.aculab.com>
On Wed, Feb 27, 2019 at 10:11:14AM +0000, David Laight wrote:
> From: Leslie Monis
> > Sent: 27 February 2019 01:00
> > Use div_u64() to resolve build failures on 32-bit platforms.
> >
> > Fixes: 3f7ae5f3dc52 ("net: sched: pie: add more cases to auto-tune alpha and beta")
> > Signed-off-by: Leslie Monis <lesliemonis@gmail.com>
> > ---
> > net/sched/sch_pie.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/net/sched/sch_pie.c b/net/sched/sch_pie.c
> > index 4c0670b6aec1..f93cfe034c72 100644
> > --- a/net/sched/sch_pie.c
> > +++ b/net/sched/sch_pie.c
> > @@ -429,7 +429,7 @@ static void calculate_probability(struct Qdisc *sch)
> > */
> >
> > if (qdelay == 0 && qdelay_old == 0 && update_prob)
> > - q->vars.prob = (q->vars.prob * 98) / 100;
> > + q->vars.prob = 98 * div_u64(q->vars.prob, 100);
>
> This has significantly different rounding after the change.
> The result for small values is very different.
> The alterative:
> q->vars.prob -= div_u64(q->vars.prob, 50);
> is much nearer to the original - but never goes to zero.
>
> If the 98% decay factor isn't critical then you could remove
> 1/64th or 1/32nd + 1/16th to avoid the slow division.
>
> David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)
>
Hi David,
You're right, the change does make the result for small
values different. I made it anyway as the probability
value is scaled by u64. It is safe to say that q->vars.prob
holds relatively large values (in its scaled form) in all
cases where it isn't 0.
But, I think we can avoid the slow division here. RFC 8033
does say that using (1 - 1/64) should be sufficient. This
will give us:
q-vars.prob -= q->vars.prob >> 6;
which I feel would be much better. What do you reckon?
Thanks a lot for the feedback.
Cheers,
Leslie
^ permalink raw reply
* Re: [PATCH net v3 2/2] selftests: pmtu: add explicit tests for PMTU exceptions cleanup
From: David Ahern @ 2019-02-27 16:18 UTC (permalink / raw)
To: Paolo Abeni, netdev; +Cc: David S. Miller, Stefano Brivio, Sabrina Dubroca
In-Reply-To: <acec2def2f7f6d254c539c9dd5fb2001f1845524.1551106591.git.pabeni@redhat.com>
On 2/25/19 8:08 AM, Paolo Abeni wrote:
> Add a couple of new tests, explicitly checking that the kernel
> timely releases PMTU exceptions on related device removal.
> This is mostly a regression test vs the issue fixed by
> commit f5b51fe804ec ("ipv6: route: purge exception on removal")
>
> Only 2 new test cases have been added, instead of extending all
> the existing ones, because the reproducer requires executing
> several commands and would slow down too much the tests otherwise.
>
> v2 -> v3:
> - more cleanup, still from Stefano
>
> v1 -> v2:
> - several script cleanups, as suggested by Stefano
>
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> ---
> tools/testing/selftests/net/pmtu.sh | 68 ++++++++++++++++++++++++++++-
> 1 file changed, 67 insertions(+), 1 deletion(-)
>
Reviewed-by: David Ahern <dsahern@gmail.com>
Thanks for adding the tests.
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the rdma tree
From: Doug Ledford @ 2019-02-27 16:24 UTC (permalink / raw)
To: Stephen Rothwell, David Miller, Networking, Jason Gunthorpe
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Shamir Rabinovitch, Jakub Kicinski
In-Reply-To: <20190227112522.2f32b5d7@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1101 bytes --]
On Wed, 2019-02-27 at 11:25 +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> drivers/infiniband/hw/mlx4/Kconfig
>
> between commit:
>
> 6fa8f1afd337 ("IB/{core,uverbs}: Move ib_umem_xxx functions from ib_core to ib_uverbs")
>
> from the rdma tree and commit:
>
> f4b6bcc7002f ("net: devlink: turn devlink into a built-in")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
Thanks Stephen, we'll add it to the (largish this release) list of
conflicts to bring to Linus' attention.
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH iproute2-next] rdma: Add the prefix for driver attributes
From: David Ahern @ 2019-02-27 16:26 UTC (permalink / raw)
To: Leon Romanovsky, Lijun Ou, Steve Wise
Cc: Leon Romanovsky, netdev, RDMA mailing list, Stephen Hemminger
In-Reply-To: <20190227064151.25445-1-leon@kernel.org>
On 2/26/19 11:41 PM, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@mellanox.com>
>
> There is a need to distinguish between driver vs. general exposed
> attributes. The most common use case is to expose some internal
> garbage under extremely common and sexy name, e.g. pi, ci e.t.c
>
> In order to achieve that, we will add "drv_" prefix to all strings
> which were received through RDMA_NLDEV_ATTR_DRIVER_* attributes.
>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>a
> ---
> rdma/utils.c | 34 ++++++++++++++++++++++------------
> 1 file changed, 22 insertions(+), 12 deletions(-)
>
applied to iproute2-next. Thanks
^ permalink raw reply
* Re: [PATCH iproute2-next] devlink: add support for updating device flash
From: David Ahern @ 2019-02-27 16:26 UTC (permalink / raw)
To: Jakub Kicinski, jiri, stephen; +Cc: oss-drivers, netdev
In-Reply-To: <20190226202014.23626-1-jakub.kicinski@netronome.com>
On 2/26/19 1:20 PM, Jakub Kicinski wrote:
> Add new command for updating flash of devices via devlink API.
> Example:
>
> $ cp flash-boot.bin /lib/firmware/
> $ devlink dev flash pci/0000:05:00.0 file flash-boot.bin
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> ---
> devlink/devlink.c | 54 ++++++++++++++++++++++++++++++++++++++++++
> man/man8/devlink-dev.8 | 32 +++++++++++++++++++++++++
> 2 files changed, 86 insertions(+)
>
applied to iproute2-next after updating the headers. Thanks
^ permalink raw reply
* RE: [PATCH net 4/4] tls: Fix tls_device receive
From: Vakul Garg @ 2019-02-27 16:28 UTC (permalink / raw)
To: Boris Pismenny, Dave Watson
Cc: Aviad Yehezkel, john.fastabend@gmail.com, daniel@iogearbox.net,
netdev@vger.kernel.org, Eran Ben Elisha
In-Reply-To: <e35a912b-7f09-92f9-8f3c-bbf0def3eae0@mellanox.com>
> -----Original Message-----
> From: Boris Pismenny <borisp@mellanox.com>
> Sent: Wednesday, February 27, 2019 8:54 PM
> To: Vakul Garg <vakul.garg@nxp.com>; Dave Watson
> <davejwatson@fb.com>
> Cc: Aviad Yehezkel <aviadye@mellanox.com>; john.fastabend@gmail.com;
> daniel@iogearbox.net; netdev@vger.kernel.org; Eran Ben Elisha
> <eranbe@mellanox.com>
> Subject: Re: [PATCH net 4/4] tls: Fix tls_device receive
>
>
>
> On 2/27/2019 5:08 AM, Vakul Garg wrote:
> >
> >
> >> -----Original Message-----
> >> From: Dave Watson <davejwatson@fb.com>
> >> Sent: Wednesday, February 27, 2019 2:05 AM
> >> To: Boris Pismenny <borisp@mellanox.com>
> >> Cc: aviadye@mellanox.com; john.fastabend@gmail.com;
> >> daniel@iogearbox.net; Vakul Garg <vakul.garg@nxp.com>;
> >> netdev@vger.kernel.org; eranbe@mellanox.com
> >> Subject: Re: [PATCH net 4/4] tls: Fix tls_device receive
> >>
> >> On 02/26/19 02:12 PM, Boris Pismenny wrote:
> >>> Currently, the receive function fails to handle records already
> >>> decrypted by the device due to the commit mentioned below.
> >>>
> >>> This commit advances the TLS record sequence number and prepares the
> >>> context to handle the next record.
> >>>
> >>> Fixes: fedf201e1296 ("net: tls: Refactor control message handling on
> >>> recv")
> >>> Signed-off-by: Boris Pismenny <borisp@mellanox.com>
> >>> Reviewed-by: Eran Ben Elisha <eranbe@mellanox.com>
> >>> ---
> >>> net/tls/tls_sw.c | 15 +++++++--------
> >>> 1 file changed, 7 insertions(+), 8 deletions(-)
> >>>
> >>> diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c index
> >>> f515cd7e984e..85da10182d8d 100644
> >>> --- a/net/tls/tls_sw.c
> >>> +++ b/net/tls/tls_sw.c
> >>> @@ -1481,18 +1481,17 @@ static int decrypt_skb_update(struct sock
> >>> *sk, struct sk_buff *skb,
> >>>
> >>> return err;
> >>> }
> >>> -
> >>> - rxm->full_len -= padding_length(ctx, tls_ctx, skb);
> >>> -
> >>> - rxm->offset += prot->prepend_size;
> >>> - rxm->full_len -= prot->overhead_size;
> >>> - tls_advance_record_sn(sk, &tls_ctx->rx, version);
> >>> - ctx->decrypted = true;
> >>> - ctx->saved_data_ready(sk);
> >>> } else {
> >>> *zc = false;
> >>> }
> >>>
> >>> + rxm->full_len -= padding_length(ctx, tls_ctx, skb);
> >>> + rxm->offset += prot->prepend_size;
> >>> + rxm->full_len -= prot->overhead_size;
> >>> + tls_advance_record_sn(sk, &tls_ctx->rx, version);
> >>> + ctx->decrypted = true;
> >>> + ctx->saved_data_ready(sk);
> >>> +
> >>> return err;
> >>> }
> >>
> >> This breaks the tls.control_msg test:
> >>
> >> [ RUN ] tls.control_msg
> >> tls.c:764:tls.control_msg:Expected memcmp(buf, test_str, send_len)
> >> (18446744073709551614) == 0 (0)
> >> tls.c:777:tls.control_msg:Expected memcmp(buf, test_str, send_len)
> >> (18446744073709551614) == 0 (0)
> >> tls.control_msg: Test failed at step #8
> >>
> >> So either control message handling needs to only call
> >> decrypt_skb_update once, or we need a new flag or something to handle
> >> the device case
> >
> > I prefer to remove variable 'decrypted' in context.
> > This is no longer required as we already have an rx_list in context for
> storing decrypted records.
> > So for any record which we decrypted but did not return to user space
> > (e.g. for the case when user used recv() and it lead to decryption of
> > non-data record), we should it in rx_list.
> >
>
> IMO this is inappropriate here, because packets decrypted by tls_device are
> ready to be received, and there is no reason to bounce them through the
> rx_list.
My point was about preventing tls_sw_recvmsg() from calling decrypt_skb_update()
with an already decrypted record. The test case failed because an already decrypted record
got dequeued and passed to decrypt_skb_update() from tls_sw_recvmsg().
For packets decrypted by device, a check using skb->decrypted should be enough.
For now, I think your patch is ok.
I can submit a simplification patch for removing 'decrypted' from tls context later.
^ permalink raw reply
* Re: [PATCH v3 bpf-next 0/4] bpf: per program stats
From: Daniel Borkmann @ 2019-02-27 16:32 UTC (permalink / raw)
To: Alexei Starovoitov, davem; +Cc: edumazet, netdev, bpf, kernel-team
In-Reply-To: <20190225222842.2031962-1-ast@kernel.org>
On 02/25/2019 11:28 PM, Alexei Starovoitov wrote:
> Introduce per program stats to monitor the usage BPF
>
> v2->v3:
> - rename to run_time_ns/run_cnt everywhere
>
> v1->v2:
> - fixed u64 stats on 32-bit archs. Thanks Eric
> - use more verbose run_time_ns in json output as suggested by Andrii
> - refactored prog_alloc and clarified behavior of stats in subprogs
>
> Alexei Starovoitov (4):
> bpf: enable program stats
> bpf: expose program stats via bpf_prog_info
> tools/bpf: sync bpf.h into tools
> tools/bpftool: recognize bpf_prog_info run_time_ns and run_cnt
>
> include/linux/bpf.h | 9 +++++
> include/linux/filter.h | 20 +++++++++-
> include/uapi/linux/bpf.h | 2 +
> kernel/bpf/core.c | 31 ++++++++++++++-
> kernel/bpf/syscall.c | 39 ++++++++++++++++++-
> kernel/bpf/verifier.c | 7 +++-
> kernel/sysctl.c | 34 ++++++++++++++++
> .../bpftool/Documentation/bpftool-prog.rst | 4 +-
> tools/bpf/bpftool/prog.c | 7 ++++
> tools/include/uapi/linux/bpf.h | 2 +
> 10 files changed, 148 insertions(+), 7 deletions(-)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v3 iproute2-next 05/11] devlink: Add devlink health show command
From: David Ahern @ 2019-02-27 16:36 UTC (permalink / raw)
To: Aya Levin; +Cc: netdev, Jiri Pirko, Moshe Shemesh, Eran Ben Elisha
In-Reply-To: <1551012378-29167-6-git-send-email-ayal@mellanox.com>
On 2/24/19 5:46 AM, Aya Levin wrote:
> Add devlink health show command which displays status and configuration
> info on a specific reporter on a device or dump the info on all
> reporters on all devices. Add helper functions to display status and
> dump's time stamp.
> Example:
> $ devlink health show pci/0000:00:09.0 reporter tx
> pci/0000:00:09.0:
> name tx
> state healthy error 0 recover 1 last_dump_date 2019-02-14 last_dump_time 10:10:10 grace_period 600 auto_recover true
> $ devlink health show pci/0000:00:09.0 reporter tx -jp
> {
> "health":{
> "pci/0000:00:0a.0":[
> {
> "name":"tx",
> "state":"healthy",
> "error":0,
> "recover":1,
> "last_dump_date":"2019-Feb-14",
> "last_dump_time":"10:10:10",
> "grace_period":600,
> "auto_recover":true
> }
> ]
> }
>
> Signed-off-by: Aya Levin <ayal@mellanox.com>
> Reviewed-by: Moshe Shemesh <moshe@mellanox.com>
> Acked-by: Jiri Pirko <jiri@mellanox.com>
> ---
> devlink/devlink.c | 185 +++++++++++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 184 insertions(+), 1 deletion(-)
>
This one no longer applies. Please respin.
^ permalink raw reply
* Re: [PATCH V2] samples: bpf: fix: broken sample regarding removed function
From: Daniel Borkmann @ 2019-02-27 16:38 UTC (permalink / raw)
To: Daniel T. Lee, Alexei Starovoitov; +Cc: netdev
In-Reply-To: <20190227075226.4409-1-danieltimlee@gmail.com>
On 02/27/2019 08:52 AM, Daniel T. Lee wrote:
> Currently, running sample "task_fd_query" and "tracex3" occurs the
> following error. On kernel v5.0-rc* this sample will be unavailable
> due to the removal of function 'blk_start_request' at commit "a1ce35f".
> (function removed, as "Single Queue IO scheduler" no longer exists)
>
> $ sudo ./task_fd_query
> failed to create kprobe 'blk_start_request' error 'No such file or
> directory'
>
> This commit will change the function 'blk_start_request' to
> 'blk_mq_start_request' to fix the broken sample.
>
> Signed-off-by: Daniel T. Lee <danieltimlee@gmail.com>
Applied, thanks! (Also please make sure to test your changes in future
ahead of submission to save valuable reviewer time.)
^ permalink raw reply
* Re: [RFC] nasty corner case in unix_dgram_sendmsg()
From: Jason Baron @ 2019-02-27 16:45 UTC (permalink / raw)
To: Al Viro; +Cc: Rainer Weikusat, netdev
In-Reply-To: <20190226235912.GL2217@ZenIV.linux.org.uk>
On 2/26/19 6:59 PM, Al Viro wrote:
> On Tue, Feb 26, 2019 at 03:35:39PM -0500, Jason Baron wrote:
>
>>> I understand what the unix_dgram_peer_wake_me() is doing; I understand
>>> what unix_dgram_poll() is using it for. What I do not understand is
>>> what's the point of doing that in unix_dgram_sendmsg()...
>>>
>>
>> Hi,
>>
>> So the unix_dgram_peer_wake_me() in unix_dgram_sendmsg() is there for
>> epoll in edge-triggered mode. In that case, we want to ensure that if
>> -EAGAIN is returned a subsequent epoll_wait() is not stuck indefinitely.
>> Probably could use a comment...
>
> *owwww*
>
> Let me see if I've got it straight - you want the forwarding rearmed,
> so that it would match the behaviour of ep_poll_callback() (i.e.
> removing only when POLLFREE is passed)? Looks like an odd way to
> do it, if that's what's happening...
If unix_dgram_sendmsg() return -EAGAIN in this case, then a subsequent call
to poll()/select()/epoll_wait() is normally going to do the forwarding rearm
via unix_dgram_poll() (unless its already writeable). However, in the
special case of epoll with edge-trigger, the call to epoll_wait does not
call unix_dgram_poll() and thus the re-arm has to happen in
unix_dgram_sendmsg().
>
> While we are at it, why disarm a forwarder upon noticing that peer
> is dead? Wouldn't it be simpler to move that
> wake_up_interruptible_all(&u->peer_wait);
> in unix_release_sock() to just before
> unix_state_unlock(sk);
> a line prior? Then anyone seeing SOCK_DEAD on (locked) peer
> would be guaranteed that all forwarders are gone...
>
The condition we are checking here is unix_recvq_full(), so even if
the wakeup happens under the lock, we could end up waking up the
waiter that still sees unix_recvq_full() because the skb's aren't
freed until *after* the wakeup call. The race is described here:
51f7e95 af_unix: ensure POLLOUT on remote close() for connected dgram socket
Note, that I did have an earlier version of that patch that moved
the wake up call (instead of checking for SOCK_DEAD), see:
https://patchwork.ozlabs.org/patch/944593/
However, I thought that the explicit check for SOCK_DEAD made things
more explicit. IE we don't wait on a SOCK_DEAD socket.
> Another fun question about the same dgram sendmsg:
> if (unix_peer(sk) == other) {
> unix_peer(sk) = NULL;
> unix_dgram_peer_wake_disconnect_wakeup(sk, other);
>
> unix_state_unlock(sk);
>
> unix_dgram_disconnected(sk, other);
>
> ... and we are holding any locks at the last line. What happens
> if we have thread A doing
> decide which address to talk to
> connect(fd, that address)
> send request over fd (with send(2) or write(2))
> read reply from fd (recv(2) or read(2))
> in a loop, with thread B doing explicit sendto(2) over the same
> socket?
>
> Suppose B happens to send to the last server thread A was talking
> to and finds it just closed (e.g. because the last request from
> A had been "shut down", which server has honoured). B gets ECONNREFUSED,
> as it ought to, but it can also ends up disrupting the next exchange
> of A.
>
> Shouldn't we rather extract the skbs from that queue *before*
> dropping sk->lock? E.g. move them to a temporary queue, and flush
> that queue after we'd unlocked sk...
>
If I understand your concern, B drops the lock as above and then
A does a connect() to somewhere else and then B drops skbs from the
new source. Looks plausible. I think in general, A and B would probably
be co-ordinating if they are both reading/writing the same socket,
but I think it probably would make sense to fix this case. Note that,
unix_dgram_disconnected() is also called in unix_dgram_connect() after
the lock is dropped so that would need a similar fix.
Thanks,
-Jason
^ permalink raw reply
* Re: [PATCH] bpf: drop refcount if bpf_map_new_fd() fails in map_create()
From: Martin Lau @ 2019-02-27 16:52 UTC (permalink / raw)
To: zerons
Cc: ast@kernel.org, daniel@iogearbox.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1551278185-5219-1-git-send-email-sironhide0null@gmail.com>
On Wed, Feb 27, 2019 at 10:36:25PM +0800, zerons wrote:
> In bpf/syscall.c, map_create() first set map->usercnt to 1, a file descriptor is
> supposed to return to userspace. When bpf_map_new_fd() fails, drop the refcount.
Thanks for the patch.
Please add a Fixes tag for bug fix in the future.
Fixes: bd5f5f4ecb78 ("bpf: Add BPF_MAP_GET_FD_BY_ID")
Acked-by: Martin KaFai Lau <kafai@fb.com>
^ permalink raw reply
* Re: [BUG] net/sched : qlen can not really be per cpu ?
From: Eric Dumazet @ 2019-02-27 16:59 UTC (permalink / raw)
To: Cong Wang; +Cc: John Fastabend, Networking, Jamal Hadi Salim, Jiri Pirko
In-Reply-To: <d075c0f5-c2b5-6ea8-f09a-7af5ba4ce05b@gmail.com>
On 02/26/2019 04:56 PM, Eric Dumazet wrote:
>
>
> On 02/26/2019 03:51 PM, Cong Wang wrote:
>> On Tue, Feb 26, 2019 at 3:19 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>>
>>>
>>>
>>> On 02/25/2019 10:42 PM, Eric Dumazet wrote:
>>>> HTB + pfifo_fast as a leaf qdisc hits badly the following warning in htb_activate() :
>>>>
>>>> WARN_ON(cl->level || !cl->leaf.q || !cl->leaf.q->q.qlen);
>>>>
>>>> This is because pfifo_fast does not update sch->q.qlen, but per cpu counters.
>>>> So cl->leaf.q->q.qlen is zero.
>>>>
>>>> HFSC, CBQ, DRR, QFQ have the same problem.
>>>>
>>>> Any ideas how we can fix this ?
>>>
>>> What about something simple for stable ?
>>> ( I yet have to boot/test this )
>>
>> Is merely updating qlen sufficient for fixing it?
>>
>> I thought it is because of the lack of qdisc_tree_reduce_backlog()
>> in pfifo_fast.
>
> It does not seem to be the qdisc_tree_reduce_backlog() thing.
>
> HTB, HFSC, CBQ, DRR, QFQ only peek at their children 'qlen' to decide if there
> is at least one packet in them.
>
> The backlog is only reported for dumps, but the actual backlog value is not used in data path.
>
>
Another way to fix this would be to have a shadow version of pfifo_fast, which
basically would be the old version of it, that would be automatically selected
when used as a child of another qdisc (except mq/mqprio of course)
This seems not a stable candidate though.
^ permalink raw reply
* Re: [PATCH net] sctp: get sctphdr by offset in sctp_compute_cksum
From: Neil Horman @ 2019-02-27 17:13 UTC (permalink / raw)
To: Xin Long; +Cc: LKML, network dev, linux-sctp, davem, Marcelo Ricardo Leitner
In-Reply-To: <CADvbK_cFyjd5T-rrZTBaZCNU0RVJMHd_ouuCE-kKpSWoMpFJog@mail.gmail.com>
On Wed, Feb 27, 2019 at 08:53:26PM +0800, Xin Long wrote:
> On Tue, Feb 26, 2019 at 8:29 PM Neil Horman <nhorman@tuxdriver.com> wrote:
> >
> > On Tue, Feb 26, 2019 at 12:15:54AM +0800, Xin Long wrote:
> > > On Mon, Feb 25, 2019 at 10:08 PM Neil Horman <nhorman@tuxdriver.com> wrote:
> > > >
> > > > On Mon, Feb 25, 2019 at 09:20:44PM +0800, Xin Long wrote:
> > > > > On Mon, Feb 25, 2019 at 8:47 PM Neil Horman <nhorman@tuxdriver.com> wrote:
> > > > > >
> > > > > > On Mon, Feb 25, 2019 at 07:25:37PM +0800, Xin Long wrote:
> > > > > > > sctp_hdr(skb) only works when skb->transport_header is set properly.
> > > > > > >
> > > > > > > But in the path of nf_conntrack_in: sctp_packet() -> sctp_error()
> > > > > > >
> > > > > > > skb->transport_header is not guaranteed to be right value for sctp.
> > > > > > > It will cause to fail to check the checksum for sctp packets.
> > > > > > >
> > > > > > > So fix it by using offset, which is always right in all places.
> > > > > > >
> > > > > > > Fixes: e6d8b64b34aa ("net: sctp: fix and consolidate SCTP checksumming code")
> > > > > > > Reported-by: Li Shuang <shuali@redhat.com>
> > > > > > > Signed-off-by: Xin Long <lucien.xin@gmail.com>
> > > > > > > ---
> > > > > > > include/net/sctp/checksum.h | 2 +-
> > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > >
> > > > > > > diff --git a/include/net/sctp/checksum.h b/include/net/sctp/checksum.h
> > > > > > > index 32ee65a..1c6e6c0 100644
> > > > > > > --- a/include/net/sctp/checksum.h
> > > > > > > +++ b/include/net/sctp/checksum.h
> > > > > > > @@ -61,7 +61,7 @@ static inline __wsum sctp_csum_combine(__wsum csum, __wsum csum2,
> > > > > > > static inline __le32 sctp_compute_cksum(const struct sk_buff *skb,
> > > > > > > unsigned int offset)
> > > > > > > {
> > > > > > > - struct sctphdr *sh = sctp_hdr(skb);
> > > > > > > + struct sctphdr *sh = (struct sctphdr *)(skb->data + offset);
> > > > > > > const struct skb_checksum_ops ops = {
> > > > > > > .update = sctp_csum_update,
> > > > > > > .combine = sctp_csum_combine,
> > > > > > > --
> > > > > > > 2.1.0
> > > > > > >
> > > > > > >
> > > > > > Shouldn't you use skb_set_transport_header and skb_transport_header here?
> > > > > you mean:
> > > > > skb_set_transport_header(skb, offset);
> > > > > sh = sctp_hdr(skb);
> > > > > ?
> > > > >
> > > > > There's no place counting on here to set transport_header.
> > > > > It will be a kinda redundant job, yet skb is 'const'.
> > > > >
> > > > I'm not sure what you mean by "theres no place counting here". We have the
> > > > transport header offset, and you're doing the exact same computation that that
> > > > function does. It seems like we should use it in case the underlying
> > > > implementation changes.
> > > 1. skb_set_transport_header() and sctp_hdr() are like:
> > > skb->transport_header = skb->data - skb->head;
> > > skb->transport_header += offset
> > > sh = skb->head + skb->transport_header;
> > >
> > > 2. in this patch:
> > > sh = (struct sctphdr *)(skb->data + offset); only
> > >
> > > I think the 2nd one is better.
> > >
> > > I feel it's weird to set transport_header here if it's only for
> > > sctp_hdr(skb) in here.
> > >
> > > As for "underlying implementation changes", I don't know exactly the case
> > > but there are quite a few places doing things like:
> > > *hdr = (struct *hdr *)(skb->data + hdroff);
> > >
> > > I'd think it's safe. no?
> > >
> > Safe, yes, it just doesn't seem right. I know you've pointed out several places
> > below that rapidly compute transport offsets in a one-off fashion, but at this
> > same time, the other primary transports (tcp and udp), all seems to use the
> > transport header to do their work (linearizing as necessecary, which sctp also
> > does in sctp_rcv, at least in most cases).
> > > >
> > > > I understand what you are saying regarding the use of a const variable there,
> > > > but perhaps thats an argument for removing the const storage classifier. Better
> > > > still, it would be good to figure out why all paths to this function don't
> > > > already set the transport header offset to begin with (addressing your redundant
> > > > comment)
> > > The issue was reported when going to nf_conntrack by br_netfilter's
> > > bridge-nf-call-iptables.
> > > As you can see on nf_conntrack_in() path, even iphdr is got by:
> > > iph = skb_header_pointer(skb, nhoff, sizeof(_iph), &_iph);
> > > It's impossible to set skb->transport_header when we're not sure iphdr
> > > in linearized memory.
> > >
> > But if the skb isn't linearized, computing the transport header manually isn't
> > going to help you anyway. You can see that in skb_header_pointer. If the
> > offset they are trying to get to is outside the bounds of the length of the skb
> > (i.e. the fragmented case), it calls skb_copy_bits to linearize the needed
> > segment. It seems we should be doing something simmilar. In most cases we are
> > already linearized from sctp_rcv (possibly all, I need to think about that). All
> > I'm really saying is that by using the skb apis we insulate ourselves from
> > potential changes in how skbs might work in the future. I'm not strictly bound
> > to setting the transport header, but we should definately be getting the
> > transport header via the skb utility functions wherever possible.
> Okay, I will change to fix it with the below patch if you agree.
> I've confirmed this won't affect netfilter.
>
> diff --git a/net/netfilter/nf_conntrack_proto_sctp.c
> b/net/netfilter/nf_conntrack_proto_sctp.c
> index d53e3e7..6b53cd2 100644
> --- a/net/netfilter/nf_conntrack_proto_sctp.c
> +++ b/net/netfilter/nf_conntrack_proto_sctp.c
> @@ -343,7 +343,9 @@ static bool sctp_error(struct sk_buff *skb,
> logmsg = "nf_ct_sctp: failed to read header ";
> goto out_invalid;
> }
> - sh = (const struct sctphdr *)(skb->data + dataoff);
> + /* sctp_compute_cksum() depends on correct transport header */
> + skb_set_transport_header(skb, dataoff);
> + sh = sctp_hdr(skb);
>
Thank you, that looks much better to me.
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [PATCH net-next 2/8] devlink: add PF and VF port flavours
From: Jakub Kicinski @ 2019-02-27 17:23 UTC (permalink / raw)
To: Jiri Pirko; +Cc: davem, oss-drivers, netdev
In-Reply-To: <20190227124135.GB10571@nanopsycho>
On Wed, 27 Feb 2019 13:41:35 +0100, Jiri Pirko wrote:
> Wed, Feb 27, 2019 at 01:23:27PM CET, jiri@resnulli.us wrote:
> >Tue, Feb 26, 2019 at 07:24:30PM CET, jakub.kicinski@netronome.com wrote:
> >>Current port flavours cover simple switches and DSA. Add PF
> >>and VF flavours to cover "switchdev" SR-IOV NICs.
> >>
> >>Example devlink user space output:
> >>
> >>$ devlink port
> >>pci/0000:82:00.0/0: type eth netdev p4p1 flavour physical
> >>pci/0000:82:00.0/10000: type eth netdev eth0 flavour pcie_pf pf 0
> >>pci/0000:82:00.0/10001: type eth netdev eth1 flavour pcie_vf pf 0 vf 0
> >>pci/0000:82:00.0/10002: type eth netdev eth2 flavour pcie_vf pf 0 vf 1
> >
> >Wait a second, howcome pf and vfs have the same PCI address?
>
> Oh, I think you have these as eswitch port representors. Confusing...
FWIW I don't like the word representor, its a port. We don't call
physical ports "representors" even though from ASIC's point of view
they are exactly the same.
^ permalink raw reply
* Re: [PATCH v4 perf,bpf 07/15] perf, bpf: save bpf_prog_info information as headers to perf.data
From: Song Liu @ 2019-02-27 17:28 UTC (permalink / raw)
To: Jiri Olsa
Cc: Netdev, linux-kernel, Alexei Starovoitov, Daniel Borkmann,
Kernel Team, Peter Zijlstra, Arnaldo Carvalho de Melo, Jiri Olsa,
Namhyung Kim
In-Reply-To: <20190227132155.GI18893@krava>
> On Feb 27, 2019, at 5:21 AM, Jiri Olsa <jolsa@redhat.com> wrote:
>
> On Mon, Feb 25, 2019 at 04:20:11PM -0800, Song Liu wrote:
>
> SNIP
>
>> + if (info_len > sizeof(struct bpf_prog_info)) {
>> + pr_warning("detected invalid bpf_prog_info\n");
>> + goto out;
>> + }
>> +
>> + info_linear = malloc(sizeof(struct bpf_prog_info_linear) +
>> + data_len);
>> + if (!info_linear)
>> + goto out;
>> + info_linear->info_len = sizeof(struct bpf_prog_info);
>> + info_linear->data_len = data_len;
>> + if (do_read_u64(ff, (u64 *)(&info_linear->arrays)))
>> + goto out;
>> + if (__do_read(ff, &info_linear->info, info_len))
>> + goto out;
>> + if (info_len < sizeof(struct bpf_prog_info))
>> + memset(((void *)(&info_linear->info)) + info_len, 0,
>> + sizeof(struct bpf_prog_info) - info_len);
>> +
>> + if (__do_read(ff, info_linear->data, data_len))
>> + goto out;
>> +
>> + /* endian mismatch, drop the info, continue */
>
> so there's no way we can swap the data? why?
>
> jirka
Yes, we can swap the data. OTOH, the set is big enough. How about we
implement the swap later? Running perf-report on a system of with
different endianness is a relatively rare case.
Thanks,
Song
>> + if (ff->ph->needs_swap) {
>> + free(info_linear);
>> + continue;
>> + }
>
> SNIP
^ permalink raw reply
* Re: [PATCH net] bnxt_en: Drop oversize TX packets to prevent errors.
From: David Miller @ 2019-02-27 17:30 UTC (permalink / raw)
To: michael.chan; +Cc: netdev
In-Reply-To: <1551257933-13270-1-git-send-email-michael.chan@broadcom.com>
From: Michael Chan <michael.chan@broadcom.com>
Date: Wed, 27 Feb 2019 03:58:53 -0500
> There have been reports of oversize UDP packets being sent to the
> driver to be transmitted, causing error conditions. The issue is
> likely caused by the dst of the SKB switching between 'lo' with
> 64K MTU and the hardware device with a smaller MTU. Patches are
> being proposed by Mahesh Bandewar <maheshb@google.com> to fix the
> issue.
>
> In the meantime, add a quick length check in the driver to prevent
> the error. The driver uses the TX packet size as index to look up an
> array to setup the TX BD. The array is large enough to support all MTU
> sizes supported by the driver. The oversize TX packet causes the
> driver to index beyond the array and put garbage values into the
> TX BD. Add a simple check to prevent this.
>
> Signed-off-by: Michael Chan <michael.chan@broadcom.com>
> ---
>
> David, I think this should be queued for stable as well.
Applied and queued up for -stable.
Thanks for following up on this Michael.
^ permalink raw reply
* [PATCH v2 2/2] dt-bindings: net: can: binding for CTU CAN FD open-source IP core.
From: pisa @ 2019-02-27 17:26 UTC (permalink / raw)
To: devicetree, mkl, linux-can
Cc: wg, davem, robh+dt, mark.rutland, netdev, linux-kernel,
martin.jerabek01, ondrej.ille, Pavel Pisa
In-Reply-To: <cover.1551287365.git.pisa@cmp.felk.cvut.cz>
From: Pavel Pisa <pisa@cmp.felk.cvut.cz>
Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz>
---
.../devicetree/bindings/net/can/ctu,ctucanfd.txt | 108 +++++++++++++++++++++
1 file changed, 108 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/can/ctu,ctucanfd.txt
diff --git a/Documentation/devicetree/bindings/net/can/ctu,ctucanfd.txt b/Documentation/devicetree/bindings/net/can/ctu,ctucanfd.txt
new file mode 100644
index 000000000000..fea9c08b79ec
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/ctu,ctucanfd.txt
@@ -0,0 +1,108 @@
+Memory mapped CTU CAN FD open-source IP core
+
+The core sources and documentation on project page
+
+ https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core
+ http://canbus.pages.fel.cvut.cz/ctucanfd_ip_core/Progdokum.pdf
+
+Integration in Xilinx Zynq SoC based system together with
+OpenCores SJA1000 compatible controllers
+
+ https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top
+
+Martin Jerabek's dimploma thesis with integration and testing
+framework description
+
+ https://dspace.cvut.cz/bitstream/handle/10467/80366/F3-DP-2019-Jerabek-Martin-Jerabek-thesis-2019-canfd.pdf
+
+Required properties:
+
+- compatible : should be one of "ctu,ctucanfd", "ctu,canfd-2".
+ The "canfd-2" has been reserved for older revision of the IP core.
+ The revision can be read from the IP core register as well.
+
+- reg = <(baseaddr) (size)> : specify mapping into physical address
+ space of the processor system.
+
+- interrupts : property with a value describing the interrupt source
+ required for the CTU CAN FD. For Zynq SoC system format is
+ <(is_spi) (number) (type)> where is_spi defines if it is SPI
+ (shared peripheral) interrupt, the second number is translated
+ to the vector by addition of 32 on Zynq-7000 systems and type
+ is IRQ_TYPE_LEVEL_HIGH (4) for Zynq.
+
+- interrupt-parent = <&interrupt-controller-phandle> :
+ is required for Zynq SoC to find map interrupt
+ to the correct controller
+
+- clocks: phandle of reference clock (100 MHz is appropriate
+ for FPGA implementation on Zynq-7000 system).
+
+Optional properties:
+
+- clock-names: not used in actual design but if more clocks are used
+ by cores then "can_clk" would be clock source name for the clocks
+ used to define CAN time-quanta.
+
+Example when integrated to Zynq-7000 system DTS:
+
+ / {
+ /* ... */
+ amba: amba {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+
+ ctu_can_fd_0: ctu_can_fd@43c30000 {
+ compatible = "ctu,ctucanfd";
+ interrupt-parent = <&intc>;
+ interrupts = <0 30 4>;
+ clocks = <&clkc 15>;
+ reg = <0x43c30000 0x10000>;
+ };
+ };
+ };
+
+
+Example when used as DTS overlay on Zynq-7000 system:
+
+
+// Device Tree Example: Full Reconfiguration without Bridges
+/dts-v1/;
+/plugin/;
+
+/ {
+ fragment@0 {
+ target-path = "/fpga-full";
+
+ __overlay__ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ firmware-name = "system.bit.bin";
+ };
+ };
+
+ fragment@1 {
+ target-path = "/amba";
+ __overlay__ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ ctu_can_fd_0: ctu_can_fd@43c30000 {
+ compatible = "ctu,ctucanfd";
+ interrupt-parent = <&intc>;
+ interrupts = <0 30 4>;
+ clocks = <&clkc 15>;
+ reg = <0x43c30000 0x10000>;
+ };
+ ctu_can_fd_1: ctu_can_fd@43c70000 {
+ compatible = "ctu,ctucanfd";
+ interrupt-parent = <&intc>;
+ interrupts = <0 31 4>;
+ clocks = <&clkc 15>;
+ reg = <0x43c70000 0x10000>;
+ };
+ };
+ };
+};
--
2.11.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox