search for: kthread_queue_worker

On 29/11/17 09:41, Corentin Labbe wrote: > The crypto engine could actually only enqueue hash and ablkcipher request. > This patch permit it to enqueue any type of crypto_async_request. > > Signed-off-by: Corentin Labbe <clabbe.montjoie at gmail.com> > --- > crypto/crypto_engine.c | 188 +++++++++++------------------------------------- > include/crypto/engine.h | 46

On 29/11/17 09:41, Corentin Labbe wrote: > The crypto engine could actually only enqueue hash and ablkcipher request. > This patch permit it to enqueue any type of crypto_async_request. > > Signed-off-by: Corentin Labbe <clabbe.montjoie at gmail.com> > --- > crypto/crypto_engine.c | 188 +++++++++++------------------------------------- > include/crypto/engine.h | 46

On Wed, Dec 06, 2017 at 11:02:23AM +0000, Fabien DESSENNE wrote: > > > On 29/11/17 09:41, Corentin Labbe wrote: > > The crypto engine could actually only enqueue hash and ablkcipher request. > > This patch permit it to enqueue any type of crypto_async_request. > > > > Signed-off-by: Corentin Labbe <clabbe.montjoie at gmail.com> > > --- > >

The crypto engine could actually only enqueue hash and ablkcipher request. This patch permit it to enqueue any type of crypto_async_request. Signed-off-by: Corentin Labbe <clabbe.montjoie at gmail.com> --- crypto/crypto_engine.c | 188 +++++++++++------------------------------------- include/crypto/engine.h | 46 +++++------- 2 files changed, 60 insertions(+), 174 deletions(-) diff

On 03/01/18 21:11, Corentin Labbe wrote: > The crypto engine could actually only enqueue hash and ablkcipher request. > This patch permit it to enqueue any type of crypto_async_request. > > Signed-off-by: Corentin Labbe <clabbe.montjoie at gmail.com> > --- > crypto/crypto_engine.c | 230 ++++++++++++++++++++++++------------------------ > include/crypto/engine.h | 59

The crypto engine could actually only enqueue hash and ablkcipher request. This patch permit it to enqueue any type of crypto_async_request. Signed-off-by: Corentin Labbe <clabbe.montjoie at gmail.com> Tested-by: Fabien Dessenne <fabien.dessenne at st.com> --- crypto/crypto_engine.c | 301 ++++++++++++++++++++++++++---------------------- include/crypto/engine.h | 68 ++++++----- 2

Hello, On Mon, Apr 13, 2020 at 04:18:57PM -0400, Lyude Paul wrote: > Hi Tejun! Sorry to bother you, but have you had a chance to look at any of > this yet? Would like to continue moving this forward Sorry, wasn't following this thread. Have you looked at kthread_worker? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/kthread.h#n71 And, thanks a

The crypto engine could actually only enqueue hash and ablkcipher request. This patch permit it to enqueue any type of crypto_async_request. Signed-off-by: Corentin Labbe <clabbe.montjoie at gmail.com> --- crypto/crypto_engine.c | 230 ++++++++++++++++++++++++------------------------ include/crypto/engine.h | 59 +++++++------ 2 files changed, 148 insertions(+), 141 deletions(-) diff

Add some simple wrappers around incrementing/decrementing kthread_work.cancelling under lock, along with checking whether queuing is currently allowed on a given kthread_work, which we'll use want to implement work cancelling with DRM's vblank work helpers. Cc: Daniel Vetter <daniel at ffwll.ch> Cc: Tejun Heo <tj at kernel.org> Cc: Ville Syrj?l? <ville.syrjala at

Hello The current crypto_engine support only ahash and ablkcipher. My first patch which try to add skcipher was Nacked, it will add too many functions and adding other algs(aead, asymetric_key) will make the situation worst. This patchset remove all algs specific stuff and now only process generic crypto_async_request. The requests handler function pointer are now moved out of struct engine and

Hello The current crypto_engine support only ahash and ablkcipher. My first patch which try to add skcipher was Nacked, it will add too many functions and adding other algs(aead, asymetric_key) will make the situation worst. This patchset remove all algs specific stuff and now only process generic crypto_async_request. The requests handler function pointer are now moved out of struct engine and

Hello The current crypto_engine support only ahash and ablkcipher request. My first patch which try to add skcipher was Nacked, it will add too many functions and adding other algs(aead, asymetric_key) will make the situation worst. This patchset remove all algs specific stuff and now only process generic crypto_async_request. The requests handler function pointer are now moved out of struct

Hello The current crypto_engine support only ahash and ablkcipher request. My first patch which try to add skcipher was Nacked, it will add too many functions and adding other algs(aead, asymetric_key) will make the situation worst. This patchset remove all algs specific stuff and now only process generic crypto_async_request. The requests handler function pointer are now moved out of struct

Currently, it's only possible to flush on a kthread_work in contexts where it's possible to block. This can be kind of painful though when trying to implement new types of delayed work which use kthread_work, since it means we'd need to drop any spinlocks for new delayed work implementations before we can actually call kthread_flush_work(). In the time between dropping locks and

Hello The current crypto_engine support only ahash and ablkcipher request. My first patch which try to add skcipher was Nacked, it will add too many functions and adding other algs(aead, asymetric_key) will make the situation worst. This patchset remove all algs specific stuff and now only process generic crypto_async_request. The requests handler function pointer are now moved out of struct

On Thu, Mar 2, 2023 at 7:35?PM Stefano Garzarella <sgarzare at redhat.com> wrote: > > The new "use_va" module parameter (default: false) is used in > vdpa_alloc_device() to inform the vDPA framework that the device > supports VA. > > vringh is initialized to use VA only when "use_va" is true and the > user's mm has been bound. So, only when the

? 2023/3/21 23:48, Stefano Garzarella ??: > The new "use_va" module parameter (default: true) is used in > vdpa_alloc_device() to inform the vDPA framework that the device > supports VA. > > vringh is initialized to use VA only when "use_va" is true and the > user's mm has been bound. So, only when the bus supports user VA > (e.g. vhost-vdpa). > >

Add some kind of vblank workers. The interface is similar to regular delayed works, and is mostly based off kthread_work. It allows for scheduling delayed works that execute once a particular vblank sequence has passed. It also allows for accurate flushing of scheduled vblank works - in that flushing waits for both the vblank sequence and job execution to complete, or for the work to get cancelled

...> Sorry, wasn't following this thread. Have you looked at kthread_worker? > Hi, thanks for the response! And yes-I think this would actually be perfect for what we need, I guess one question I might as well ask since I've got you here: would patches to expose an unlocked version of kthread_queue_worker() be accepted? With something like that I should be able to just reuse the delayed_work_list and spinlocks that come with kthread_worker which would make the vblank works implementation a bit easier > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/kt...

Let's move work management inside the vdpa_sim core. This way we can easily change how we manage the works, without having to change the devices each time. Acked-by: Eugenio P??rez Martin <eperezma at redhat.com> Acked-by: Jason Wang <jasowang at redhat.com> Signed-off-by: Stefano Garzarella <sgarzare at redhat.com> --- drivers/vdpa/vdpa_sim/vdpa_sim.h | 3 ++-