that did that, and I don't remember the history. I thought it was
> required by some spec or peer implementation (maybe Windows?) but I
> really don't remember. It may predate git. I'll dig around and see
> what I can find.
I can't add more here, this design comes from well before I started
working on this body of code (though, I worked near Kevin when he
implemented it).
--
Chuck Lever
> On Nov 12, 2020, at 4:07 PM, Bruce Fields wrote:
>
> On Thu, Nov 12, 2020 at 04:54:06PM +, David Howells wrote:
>> Chuck Lever wrote:
>>
>>> Really? My understanding of the Linux kernel SUNRPC implementation is
>>> that it uses asynchronous, eve
pc/rxgk.c | 1232 ++
>> net/rxrpc/rxgk_app.c | 424 ++++++
>> net/rxrpc/rxgk_common.h | 164
>> net/rxrpc/rxgk_kdf.c | 271 +++
>> net/rxrpc/security.c |6 +
>> 26 files changed, 5530 insertions(+), 1 deletion(-)
>> create mode 100644 crypto/krb5/kdf.c
>> create mode 100644 crypto/krb5/rfc3961_simplified.c
>> create mode 100644 crypto/krb5/rfc3962_aes.c
>> create mode 100644 crypto/krb5/rfc6803_camellia.c
>> create mode 100644 crypto/krb5/rfc8009_aes2.c
>> create mode 100644 crypto/krb5/selftest.c
>> create mode 100644 crypto/krb5/selftest_data.c
>> create mode 100644 net/rxrpc/rxgk.c
>> create mode 100644 net/rxrpc/rxgk_app.c
>> create mode 100644 net/rxrpc/rxgk_common.h
>> create mode 100644 net/rxrpc/rxgk_kdf.c
--
Chuck Lever
> On Nov 12, 2020, at 10:42 AM, David Howells wrote:
>
> Chuck Lever wrote:
>
>>> There are three main interfaces to it:
>>>
>>> (*) I/O crypto: encrypt, decrypt, get_mic and verify_mic.
>>>
>>>These all do in-place crypto, usi
d.c
> create mode 100644 crypto/krb5/rfc3962_aes.c
> create mode 100644 crypto/krb5/rfc6803_camellia.c
> create mode 100644 crypto/krb5/rfc8009_aes2.c
> create mode 100644 crypto/krb5/selftest.c
> create mode 100644 crypto/krb5/selftest_data.c
> create mode 100644 net/rxrpc/rxgk.c
> create mode 100644 net/rxrpc/rxgk_app.c
> create mode 100644 net/rxrpc/rxgk_common.h
> create mode 100644 net/rxrpc/rxgk_kdf.c
>
>
--
Chuck Lever
> On May 4, 2020, at 3:07 PM, bfie...@fieldses.org wrote:
>
> On Fri, May 01, 2020 at 03:04:00PM -0400, Chuck Lever wrote:
>> Over the past year or so I've observed that using sec=krb5i or
>> sec=krb5p with NFS/RDMA while testing my Linux NFS client and server
>>
trying to understand how to come up with a solution that
prevents the rescheduling/connection loss issue without also
causing a performance regression.
Any thoughts/comments/advice appreciated.
---
Chuck Lever (1):
SUNRPC: crypto calls should never schedule
--
Chuck Lever
risk of removing the cond_resched() is low.
A block of data handled in these paths will not exceed 1MB + a
little a overhead, and processing a single RPC is already
appropriately interleaved amongst both processes and CPUs.
Signed-off-by: Chuck Lever
---
net/sunrpc/auth_gss/gss_krb5_crypto.c |8
