similar to: [PATCH] Fix compile warnings in virtio_balloon

Workqueues have clean and rich API for all basic operations. The code is usually easier and better readable. It can be easily tuned for the given purpose. In many cases, it allows to avoid an extra kernel thread. It helps to stop the growing number of them. Also there will be less thread-specific hacks all over the kernel code. It forces making the task selfcontained. There is no longer an

Workqueues have clean and rich API for all basic operations. The code is usually easier and better readable. It can be easily tuned for the given purpose. In many cases, it allows to avoid an extra kernel thread. It helps to stop the growing number of them. Also there will be less thread-specific hacks all over the kernel code. It forces making the task selfcontained. There is no longer an

We recently added locking in fill_balloon() but there was one error path which was missed. Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com> --- Only needed in linux-next. diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c index f70151b..1c50e98 100644 --- a/drivers/virtio/virtio_balloon.c +++ b/drivers/virtio/virtio_balloon.c @@ -153,9 +153,10 @@

We recently added locking in fill_balloon() but there was one error path which was missed. Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com> --- Only needed in linux-next. diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c index f70151b..1c50e98 100644 --- a/drivers/virtio/virtio_balloon.c +++ b/drivers/virtio/virtio_balloon.c @@ -153,9 +153,10 @@

Workqueues have clean and rich API for all basic operations. The code is usually easier and better readable. It can be easily tuned for the given purpose. In many cases, it allows to avoid an extra kernel thread. It helps to stop the growing number of them. Also there will be less thread-specific hacks all over the kernel code. It forces making the task selfcontained. There is no longer an

Workqueues have clean and rich API for all basic operations. The code is usually easier and better readable. It can be easily tuned for the given purpose. In many cases, it allows to avoid an extra kernel thread. It helps to stop the growing number of them. Also there will be less thread-specific hacks all over the kernel code. It forces making the task selfcontained. There is no longer an

On Fri, Dec 04, 2015 at 02:37:50PM +0100, Petr Mladek wrote: > fill_balloon() and leak_balloon() manipulate only a limited number > of pages in one call. This is the reason why remove_common() calls > leak_balloon() in a while cycle. > > remove_common() is called also when the system is being frozen. > But fill_balloon() is called only once when the system is being >

On Fri, Dec 04, 2015 at 02:37:50PM +0100, Petr Mladek wrote: > fill_balloon() and leak_balloon() manipulate only a limited number > of pages in one call. This is the reason why remove_common() calls > leak_balloon() in a while cycle. > > remove_common() is called also when the system is being frozen. > But fill_balloon() is called only once when the system is being >

fill_balloon doing memory allocations under balloon_lock can cause a deadlock when leak_balloon is called from virtballoon_oom_notify and tries to take same lock. To fix, split page allocation and enqueue and do allocations outside the lock. Here's a detailed analysis of the deadlock by Tetsuo Handa: In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to serialize

fill_balloon doing memory allocations under balloon_lock can cause a deadlock when leak_balloon is called from virtballoon_oom_notify and tries to take same lock. To fix, split page allocation and enqueue and do allocations outside the lock. Here's a detailed analysis of the deadlock by Tetsuo Handa: In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to serialize

From: Wei Yongjun <yongjun_wei at trendmicro.com.cn> Add the missing unlock before return from function fill_balloon() in the error handling case. Introduced by 9864a8(virtio_balloon: introduce migration primitives to balloon pages) dpatch engine is used to auto generate this patch. (https://github.com/weiyj/dpatch) Signed-off-by: Wei Yongjun <yongjun_wei at trendmicro.com.cn> ---

From: Wei Yongjun <yongjun_wei at trendmicro.com.cn> Add the missing unlock before return from function fill_balloon() in the error handling case. Introduced by 9864a8(virtio_balloon: introduce migration primitives to balloon pages) dpatch engine is used to auto generate this patch. (https://github.com/weiyj/dpatch) Signed-off-by: Wei Yongjun <yongjun_wei at trendmicro.com.cn> ---

On Fri, Dec 01, 2017 at 11:31:08PM +1100, Michael Ellerman wrote: > "Michael S. Tsirkin" <mst at redhat.com> writes: > > > fill_balloon doing memory allocations under balloon_lock > > can cause a deadlock when leak_balloon is called from > > virtballoon_oom_notify and tries to take same lock. > > > > To fix, split page allocation and enqueue and

On Fri, Dec 01, 2017 at 11:31:08PM +1100, Michael Ellerman wrote: > "Michael S. Tsirkin" <mst at redhat.com> writes: > > > fill_balloon doing memory allocations under balloon_lock > > can cause a deadlock when leak_balloon is called from > > virtballoon_oom_notify and tries to take same lock. > > > > To fix, split page allocation and enqueue and

fill_balloon doing memory allocations under balloon_lock can cause a deadlock when leak_balloon is called from virtballoon_oom_notify and tries to take same lock. To fix, split page allocation and enqueue and do allocations outside the lock. Here's a detailed analysis of the deadlock by Tetsuo Handa: In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to serialize

fill_balloon doing memory allocations under balloon_lock can cause a deadlock when leak_balloon is called from virtballoon_oom_notify and tries to take same lock. To fix, split page allocation and enqueue and do allocations outside the lock. Here's a detailed analysis of the deadlock by Tetsuo Handa: In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to serialize

It has been long since I have sent v3 of the balloon conversion from a kthread to a workqueue. I have gained some more experience with the APIs in the meantime. I hope that you would like the outcome. I have added one more patch that fixes a separate problem with restoring the balloon after the system freeze. I have found this when testing the conversion. Changes against v3: + rebased on

It has been long since I have sent v3 of the balloon conversion from a kthread to a workqueue. I have gained some more experience with the APIs in the meantime. I hope that you would like the outcome. I have added one more patch that fixes a separate problem with restoring the balloon after the system freeze. I have found this when testing the conversion. Changes against v3: + rebased on

On Wed, Feb 05, 2020 at 05:34:02PM +0100, David Hildenbrand wrote: > Commit 71994620bb25 ("virtio_balloon: replace oom notifier with shrinker") > changed the behavior when deflation happens automatically. Instead of > deflating when called by the OOM handler, the shrinker is used. > > However, the balloon is not simply some slab cache that should be > shrunk when under

On Wed, Feb 05, 2020 at 05:34:02PM +0100, David Hildenbrand wrote: > Commit 71994620bb25 ("virtio_balloon: replace oom notifier with shrinker") > changed the behavior when deflation happens automatically. Instead of > deflating when called by the OOM handler, the shrinker is used. > > However, the balloon is not simply some slab cache that should be > shrunk when under