search for: kthreads

On 3/11/23 2:53 AM, Christian Brauner wrote: > On Fri, Mar 10, 2023 at 04:03:24PM -0600, Mike Christie wrote: >> This has us pass in the thread's name during creation in kernel_thread. >> >> Signed-off-by: Mike Christie <michael.christie at oracle.com> >> --- >> kernel/kthread.c | 35 ++++++++++++++--------------------- >> 1 file changed, 14

Hi, after a while of playing around with winedbg i have a lot of these: bash-2.05b# ps -A 559 pts/0 00:00:01 wine-kthread <defunct> 558 pts/0 00:00:04 wine-kthread <defunct> 607 pts/0 00:00:01 wine-kthread <defunct> 606 pts/0 00:00:04 wine-kthread <defunct> i tried differend variations on kill, and killall, but they don't go away. Any ideas? Regards,

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

Hi all, I have updated my Centos 6.5 KVM host to kernel 2.6.32-431.23.3 this morning ... After 2 hours working, the following kernel error appears and all vm guests goes slowly .... device monif4 entered promiscuous mode monif: port 5(monif4) entering forwarding state INFO: task cgroup:83 blocked for more than 120 seconds. Not tainted 2.6.32-431.23.3.el6.x86_64 #1 "echo 0 >

...> On Tue 2023-01-24 11:21:39, Seth Forshee wrote: > > > On Tue, Jan 24, 2023 at 03:17:43PM +0100, Petr Mladek wrote: > > > > On Fri 2023-01-20 16:12:22, Seth Forshee (DigitalOcean) wrote: > > > > > Livepatch relies on stack checking of sleeping tasks to switch kthreads, > > > > > so a busy kthread can block a livepatch transition indefinitely. We've > > > > > seen this happen fairly often with busy vhost kthreads. > > > > > > > > > --- a/drivers/vhost/vhost.c > > > > > +++ b/drivers/vhos...

i have install wine 9.60 on linux kernel 2.6.21 and by default wine work with pthread if i force kthread any program like notepad produce segfault is possible use kthread with 2.6.21 kernel?

On Fri, Jan 20, 2023 at 04:12:20PM -0600, Seth Forshee (DigitalOcean) wrote: > We've fairly regularaly seen liveptches which cannot transition within kpatch's > timeout period due to busy vhost worker kthreads. In looking for a solution the > only answer I found was to call klp_update_patch_state() from a safe location. > I tried adding this call to vhost_worker(), and it works, but this creates the > potential for problems if a livepatch attempted to patch vhost_worker(). > Without a call to...

These helpers are only for use with kernel threads, and I will tie them more into the kthread infrastructure going forward. Also move the prototypes to kthread.h - mmu_context.h was a little weird to start with as it otherwise contains very low-level MM bits. Signed-off-by: Christoph Hellwig <hch at lst.de> --- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 1 +

Hi all, this series improves the use_mm / unuse_mm interface by better documenting the assumptions, and my taking the set_fs manipulations spread over the callers into the core API.

Hi all, this series improves the use_mm / unuse_mm interface by better documenting the assumptions, and my taking the set_fs manipulations spread over the callers into the core API.

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

Hi all, this series improves the use_mm / unuse_mm interface by better documenting the assumptions, and my taking the set_fs manipulations spread over the callers into the core API. Changes since v1: - drop a few patches - fix a comment typo - cover the newly merged use_mm/unuse_mm caller in vfio

Hi all, this series improves the use_mm / unuse_mm interface by better documenting the assumptions, and my taking the set_fs manipulations spread over the callers into the core API. Changes since v1: - drop a few patches - fix a comment typo - cover the newly merged use_mm/unuse_mm caller in vfio

...Jan 26, 2023 at 06:03:16PM +0100, Petr Mladek wrote: > > > On Fri 2023-01-20 16:12:20, Seth Forshee (DigitalOcean) wrote: > > > > We've fairly regularaly seen liveptches which cannot transition within kpatch's > > > > timeout period due to busy vhost worker kthreads. > > > > > > I have missed this detail. Miroslav told me that we have solved > > > something similar some time ago, see > > > https://lore.kernel.org/all/20220507174628.2086373-1-song at kernel.org/ > > > > Interesting thread. I had thought about so...

From: Petr Mladek <pmladek at suse.cz> This patch moves the deferred work from the "vballoon" kthread into a system freezable workqueue. We do not need to maintain and run a dedicated kthread. Also the event driven workqueues API makes the logic much easier. Especially, we do not longer need an own wait queue, wait function, and freeze point. The conversion is pretty

Switch the function documentation to kerneldoc comments, and add WARN_ON_ONCE asserts that the calling thread is a kernel thread and does not have ->mm set (or has ->mm set in the case of unuse_mm). Also give the functions a kthread_ prefix to better document the use case. Signed-off-by: Christoph Hellwig <hch at lst.de> Acked-by: Felix Kuehling <Felix.Kuehling at amd.com> ---

Hy all.. i've just subscribed to the list thow i've been using wine for a while now. I 've emeregd (I have Gentoo) the latest wine and , Here-s what i get: mihaiv bin # wine /usr/local/bin/wine-kthread: could not open mihaiv bin # /usr/local/bin/wine-kthread Wine 20041019 Usage: wine PROGRAM [ARGUMENTS...] Run the specified program wine --help Display this help and exit wine

...s better scheduling fairness among vifs - is prerequisite for implementing multiqueue for Xen network driver The first two patches are ground work for the third patch. They aim to reduce memory footprint of netback. The third patch has the real meat: - make use of NAPI to mitigate interrupt - kthreads are not bound to CPUs any more, so that we can take advantage of backend scheduler and trust it to do the right thing Wei Liu (3): xen-netback: page pool support xen-netback: switch to per-cpu scratch space xen-netback: switch to NAPI + kthread 1:1 model drivers/net/xen-netback/Makefile...

Switch the function documentation to kerneldoc comments, and add WARN_ON_ONCE asserts that the calling thread is a kernel thread and does not have ->mm set (or has ->mm set in the case of unuse_mm). Also give the functions a kthread_ prefix to better document the use case. Signed-off-by: Christoph Hellwig <hch at lst.de> --- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 4 +--

Use the proper API instead. Fixes: f440c8a572d7 ("drm/i915/gvt/kvmgt: read/write GPA via KVM API") Signed-off-by: Christoph Hellwig <hch at lst.de> --- drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c index 074c4efb58eb..5848400620b4 100644 ---