it can be resubmitted as [PATCH net].
In any case, the content is good:
Reviewed-by: Mat Martineau
--
Mat Martineau
Intel
.org/project/netdev/patch/078a2ef5bdc4e3b2c25ef852461692001f426495.1604976945.git.geliangt...@gmail.com/
Thanks!
--
Mat Martineau
Intel
df5 ("mptcp: MPTCP_IPV6 should depend on IPV6 instead of selecting
it")
Signed-off-by: Matthieu Baerts
---
tools/testing/selftests/net/mptcp/config | 1 +
1 file changed, 1 insertion(+)
Reviewed-by: Mat Martineau
--
Mat Martineau
Intel
in(struct mptcp_sock *msk, u64 data_fin_seq, bool
use_64bit);
+ void mptcp_destroy_common(struct mptcp_sock *msk);
Yes, this is the appropriate conflict resolution. Thanks!
--
Mat Martineau
Intel
- return mptcp_subflow_data_available(ssk);
+ /* old data, keep it simple and drop the whole pkt, sender
+* will retransmit as needed, if needed.
+*/
+ MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_DUPDATA);
+ mptcp_drop(sk, skb);
+ return false;
+ }
+
+ static void mptcp_stop_timer(struct sock *sk)
+ {
+ struct inet_connection_sock *icsk = inet_csk(sk);
+
+ sk_stop_timer(sk, &icsk->icsk_retransmit_timer);
+ mptcp_sk(sk)->timer_ival = 0;
}
static void mptcp_check_data_fin_ack(struct sock *sk)
--
Mat Martineau
Intel
changed, 9 insertions(+)
Reviewed-by: Mat Martineau
--
Mat Martineau
Intel
On Thu, 24 Sep 2020, Geliang Tang wrote:
This patch implemented the retransmition of ADD_ADDR when no ADD_ADDR echo
is received. It added a timer with the announced address. When timeout
occurs, ADD_ADDR will be retransmitted.
Suggested-by: Mat Martineau
Suggested-by: Paolo Abeni
Acked-by
On Thu, 24 Sep 2020, Geliang Tang wrote:
Add a new struct mptcp_pm_add_entry to describe add_addr's entry.
Acked-by: Paolo Abeni
Signed-off-by: Geliang Tang
---
net/mptcp/pm_netlink.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
Reviewed-by: Mat Mart
hieu Baerts
Suggested-by: Paolo Abeni
Suggested-by: Mat Martineau
Acked-by: Paolo Abeni
Signed-off-by: Geliang Tang
---
.../testing/selftests/net/mptcp/mptcp_join.sh | 145 +-
1 file changed, 142 insertions(+), 3 deletions(-)
Reviewed-by: Mat Martineau
--
Mat Martineau
Intel
can be sent and received completely.
Otherwise the remove address and subflow test cases don't work.
Suggested-by: Matthieu Baerts
Suggested-by: Paolo Abeni
Suggested-by: Mat Martineau
Acked-by: Paolo Abeni
Signed-off-by: Geliang Tang
---
.../selftests/net/mptcp/mptcp_connect.c
| 1 +
net/mptcp/subflow.c | 4 +---
3 files changed, 10 insertions(+), 6 deletions(-)
Reviewed-by: Mat Martineau
--
Mat Martineau
Intel
Baerts
Suggested-by: Paolo Abeni
Suggested-by: Mat Martineau
Acked-by: Paolo Abeni
Signed-off-by: Geliang Tang
---
net/mptcp/mib.c| 2 ++
net/mptcp/mib.h| 2 ++
net/mptcp/pm_netlink.c | 5 +
3 files changed, 9 insertions(+)
Reviewed-by: Mat Martineau
--
Mat Martineau
Intel
need to move
__mptcp_init_sock before the mptcp_is_enabled check in mptcp_init_sock.
Suggested-by: Matthieu Baerts
Suggested-by: Paolo Abeni
Suggested-by: Mat Martineau
Acked-by: Paolo Abeni
Signed-off-by: Geliang Tang
---
net/mptcp/pm.c | 7 ++-
net/mptcp/pm_netlink.c | 122
status, and called mptcp_pm_nl_rm_addr_received to handle
it.
In mptcp_pm_nl_rm_addr_received, we closed the subflow matching the rm_id,
and updated PM counter.
Suggested-by: Matthieu Baerts
Suggested-by: Paolo Abeni
Suggested-by: Mat Martineau
Signed-off-by: Geliang Tang
---
net/mptcp/options.c
Abeni
Signed-off-by: Geliang Tang
---
net/mptcp/options.c | 29 +
net/mptcp/pm.c | 25 +
net/mptcp/protocol.h | 9 +
3 files changed, 63 insertions(+)
Reviewed-by: Mat Martineau
--
Mat Martineau
Intel
| 12 ++--
net/mptcp/protocol.h | 10 +-
3 files changed, 18 insertions(+), 18 deletions(-)
Reviewed-by: Mat Martineau
--
Mat Martineau
Intel
b.com/multipath-tcp/mptcp_net-next/wiki - and we
are working on more documentation with the kind of pointers you're looking
for.
Thanks for trying out MPTCP!
--
Mat Martineau
Intel
when
David announces that it is open again. The change does look ok but will
not be merged now.
Thanks for your patch,
--
Mat Martineau
Intel
l.h: don't use C++ reserved keyword as a
struct member name")
Signed-off-by: David Howells
cc: Randy Dunlap
cc: Lubomir Rintel
cc: James Morris
cc: Mat Martineau
cc: Stephan Mueller
cc: Andrew Morton
cc: Linus Torvalds
cc: sta...@vger.kernel.org
---
include/uapi/linux/keyctl.h
ot;dh_private" instead to allow the header file
to be used in C++ userspace.
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=191051
Ugh. Yeah. This is a UAPI breaker, but I think we have to do it, despite it
being 2 years old. Maybe wrap that element in a #ifdef so it's still allowed
On Fri, 8 Dec 2017, David Howells wrote:
Mat Martineau wrote:
Since this fixes the bug for the asymmetric key type and ensures that other
key types won't make the same mistake, I agree this is the way to fix it. I
did not find any issues in the patch.
Can I put that down as a Review
triction);
+ ret = keyring_restrict(key_ref, _type ? type : NULL, restriction);
kfree(restriction);
-
error:
key_ref_put(key_ref);
-
return ret;
}
--
2.15.0.531.g2ccb3012c9-goog
--
Mat Martineau
Intel OTC
have
a chance I'll see if I can find a reproducer.
CONFIG_KEY_DH_OPERATIONS and use of mpi_powm() by KEYCTL_DH_COMPUTE goes
back to v4.7, when the MPI library was called directly. KPP was not
implemented yet.
--
Mat Martineau
Intel OTC
eak;
e = ep[i];
c = BITS_PER_MPI_LIMB;
+
+ cond_resched();
}
/* We shifted MOD, the modulo reduction argument, left
MOD_SHIFT_CNT
--
2.15.0
--
Mat Martineau
Intel OTC
_be_signed_hash;
+ efi_time_t time_of_revocation;
+} efi_cert_x509_sha256_t;
+
/*
* All runtime access to EFI goes through this structure:
*/
--
Mat Martineau
Intel OTC
c key algorithm is
printed in /proc/keys, but is not returned by KEYCTL_PKEY_QUERY or
KEYCTL_DESCRIBE.
Does it make sense to add the information from key->type->describe() to
KEYCTL_PKEY_QUERY or KEYCTL_DESCRIBE? Or add something new like
KEYCTL_DESCRIBE_TYPE?
--
Mat Martineau
Intel OTC
On Fri, 8 Jul 2016, Tadeusz Struk wrote:
Hi Mat,
On 07/06/2016 12:38 PM, Mat Martineau wrote:
So it looks like the only thing that we need to return to the user in
this case is the return code. Do you agree?
The way verify_signature is implemented today, the only output is the
return code
On Tue, 5 Jul 2016, Tadeusz Struk wrote:
Hi Mat,
On 06/29/2016 11:43 AM, Mat Martineau wrote:
+ret = verify_signature(key, &sig);
+if (!ret) {
+req->dst_len = sizeof(digest);
I think you fixed the BUG_ON() problem but there's still an issue with
the handling o
y in a TPM) can or can not provide the digest needed. Maybe this
is why the verify_signature hook in struct asymmetric_key_subtype is
optional.
+ scatterwalk_map_and_copy(digest, req->dst, 0, req->dst_len, 1);
+ }
+ kfree(src);
+ return ret;
+}
+
--
Mat Martineau
Intel OTC
return n >= CRYPTO_MAX_ALG_NAME ? -EINVAL : 0;
+ }
+
+ if (strcmp(encoding, "raw") == 0) {
+ strcpy(alg_name, pkey->pkey_algo);
+ return 0;
+ }
+
+ return -ENOPKG;
+}
Regards,
--
Mat Martineau
Intel OTC
Stephan and Tadeusz,
On Fri, 10 Jun 2016, Tadeusz Struk wrote:
On 06/09/2016 11:36 AM, Stephan Mueller wrote:
Am Donnerstag, 9. Juni 2016, 11:27:13 schrieb Mat Martineau:
Hi Mat, Tadeusz,
Ok, after checking the code again, I think that dropping that sanity check
should be ok given that
hould it be set to something
like -EALREADY to indicate that data is already queued for a different
crypto op?
+unlock:
+ akcipher_data_wakeup(sk);
+ release_sock(sk);
+
+ return err ?: copied;
+}
Regards,
--
Mat Martineau
Intel OTC
On Thu, 9 Jun 2016, Stephan Mueller wrote:
Am Donnerstag, 9. Juni 2016, 11:18:04 schrieb Mat Martineau:
Hi Mat,
Or is your concern that the user space interface restricts things too much
and thus prevents a valid use case?
The latter - my primary concern is the constraint this places on
On Thu, 9 Jun 2016, Stephan Mueller wrote:
Am Mittwoch, 8. Juni 2016, 12:14:49 schrieb Mat Martineau:
Hi Mat,
On Wed, 8 Jun 2016, Stephan Mueller wrote:
Am Dienstag, 7. Juni 2016, 17:28:07 schrieb Mat Martineau:
Hi Mat,
+ used = ctx->used;
+
+ /* convert iovecs of out
On Wed, 8 Jun 2016, Stephan Mueller wrote:
Am Dienstag, 7. Juni 2016, 17:28:07 schrieb Mat Martineau:
Hi Mat,
+ used = ctx->used;
+
+ /* convert iovecs of output buffers into scatterlists */
+ while (iov_iter_count(&msg->msg_iter)) {
+ /* make
* EBADMSG implies a valid cipher operation took place */
+ if (err == -EBADMSG)
+ akcipher_put_sgl(sk);
+ goto unlock;
+ }
+
+ akcipher_put_sgl(sk);
+
+unlock:
+ for (i = 0; i < cnt; i++)
+ af_alg_free_sg(&ctx->rsgl[i]);
+
+ akcipher_wmem_wakeup(sk);
+ release_sock(sk);
+
+ return err ? err : ctx->req.dst_len;
+}
--
Mat Martineau
Intel OTC
ed with all the
requisite plumbing to the asymmetric key subtype.
--
Mat Martineau
Intel OTC
akcipher_request *req)
...
+ ret = verify_signature(key, NULL, &sig);
key->type->asym_verify_signature() is available as well.
Regards,
--
Mat Martineau
Intel OTC
On Thu, 12 May 2016, David Howells wrote:
Mat Martineau wrote:
+ len = crypto_akcipher_maxsize(tfm);
+ info->key_size = len * 8;
+ info->max_data_size = len;
+ info->max_sig_size = len;
+ info->max_enc_size = len;
+ info->max_dec_size
-asn1.h
+
+clean-files+= pkcs8-asn1.c pkcs8-asn1.h
--
Mat Martineau
Intel OTC
ize = len;
+ info->max_enc_size = len;
+ info->max_dec_size = len;
If len > UINT16_MAX, should UINT16_MAX be reported as the max size?
Similar question for len*8 and key_size.
--
Mat Martineau
Intel OTC
eed to check for NULL asym_eds_op before calling.
Regards,
--
Mat Martineau
Intel OTC
t(key);
+ return ret;
+}
+
+static void keyctl_pkey_params_free(struct kernel_pkey_params *params)
+{
+ kfree(params->info);
+ key_put(params->key);
+ key_put(params->password);
+}
+
+enum {
+ Opt_err = -1,
+ Opt_enc,/* "enc=" eg. &q
35891 ("PKCS#7:
pkcs7_validate_trust(): initialize the _trusted output argument"), right
after the local declarations.
+struct key *trust_keyring)
{
struct pkcs7_signed_info *sinfo;
struct x509_certificate *p;
Regards,
--
Mat Martineau
Intel OTC
44 matches
Mail list logo
