On Thu, 4 Apr 2024, Jason Xing wrote:
From: Jason Xing
It relys on what reset options in MPTCP does as rfc8684 says. Reusing
this logic can save us much energy. This patch replaces all the prior
NOT_SPECIFIED reasons.
Signed-off-by: Jason Xing
---
net/mptcp/subflow.c | 26
n be resubmitted as [PATCH net].
In any case, the content is good:
Reviewed-by: Mat Martineau
--
Mat Martineau
Intel
project/netdev/patch/078a2ef5bdc4e3b2c25ef852461692001f426495.1604976945.git.geliangt...@gmail.com/
Thanks!
--
Mat Martineau
Intel
6 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
ruct 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
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_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
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 Martineau
eu 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| 18
| 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
this 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
-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
t is open again. The change does look ok but will
not be merged now.
Thanks for your patch,
--
Mat Martineau
Intel
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 |7 ++-
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 |7 ++-
a #ifdef so it's still allowed
in C?
cc'ing Mat Martineau as he's the originator of the structure.
I agree with David's assessment.
The keyctl() system call wrapper is implemented in libkeyutils, which may
reduce the need for the proposed ifdef. libkeyutils and its users don't
require any updates if
"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
in C?
On Fri, 8 Dec 2017, David Howells wrote:
Mat Martineau <mathew.j.martin...@linux.intel.com> 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
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 Reviewed
)
+ goto error;
}
- ret = keyring_restrict(key_ref, link_reject ? NULL : type, restriction);
+ 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
ion);
+ 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
els than v4.12. If I 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
ve
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
res, MPI base, MPI exp, MPI mod)
break;
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
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
pedef struct {
+ efi_sha256_hash_t to_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
;
+ efi_time_t time_of_revocation;
+} efi_cert_x509_sha256_t;
+
/*
* All runtime access to EFI goes through this structure:
*/
--
Mat Martineau
Intel OTC
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
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 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, );
+if (!ret) {
+req->dst_len = sizeof(digest);
I think you fixed the BUG_ON() problem but there's still an issue with
the handling of the digest. Ch
On Tue, 5 Jul 2016, Tadeusz Struk wrote:
Hi Mat,
On 06/29/2016 11:43 AM, Mat Martineau wrote:
+ret = verify_signature(key, );
+if (!ret) {
+req->dst_len = sizeof(digest);
I think you fixed the BUG_ON() problem but there's still an issue with
the handling of the digest. Ch
a key 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
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
>= 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
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
ed)
+ goto unlock;
err might be uninitialised at this goto. Should 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
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 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 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 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_iter)) {
+ /* make one iovec ava
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_iter)) {
+ /* make one iovec ava
if (err == -EBADMSG)
+ akcipher_put_sgl(sk);
+ goto unlock;
+ }
+
+ akcipher_put_sgl(sk);
+
+unlock:
+ for (i = 0; i < cnt; i++)
+ af_alg_free_sg(>rsgl[i]);
+
+ akcipher_wmem_wakeup(sk);
+ release_sock(sk);
+
+ return err ? err : ctx->req.dst_len;
+}
--
Mat Martineau
Intel OTC
+ goto unlock;
+ }
+
+ akcipher_put_sgl(sk);
+
+unlock:
+ for (i = 0; i < cnt; i++)
+ af_alg_free_sg(>rsgl[i]);
+
+ akcipher_wmem_wakeup(sk);
+ release_sock(sk);
+
+ return err ? err : ctx->req.dst_len;
+}
--
Mat Martineau
Intel OTC
e
requisite plumbing to the asymmetric key subtype.
--
Mat Martineau
Intel OTC
e
requisite plumbing to the asymmetric key subtype.
--
Mat Martineau
Intel OTC
request *req)
...
+ ret = verify_signature(key, NULL, );
key->type->asym_verify_signature() is available as well.
Regards,
--
Mat Martineau
Intel OTC
request *req)
...
+ ret = verify_signature(key, NULL, );
key->type->asym_verify_signature() is available as well.
Regards,
--
Mat Martineau
Intel OTC
On Thu, 12 May 2016, David Howells wrote:
Mat Martineau <mathew.j.martin...@linux.intel.com> wrote:
+ len = crypto_akcipher_maxsize(tfm);
+ info->key_size = len * 8;
+ info->max_data_size = len;
+ info->max_sig_size = len;
+ info->
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
-asn1.h
+
+clean-files+= pkcs8-asn1.c pkcs8-asn1.h
--
Mat Martineau
Intel OTC
+ info->max_sig_size = 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
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
check for NULL asym_eds_op before calling.
Regards,
--
Mat Martineau
Intel OTC
check for NULL asym_eds_op before calling.
Regards,
--
Mat Martineau
Intel OTC
id 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. "enc=oaep" */
endoding->encoding
id 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. "enc=oaep" */
endoding->encoding
("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
("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
71 matches
Mail list logo
