Displaying 20 results from an estimated 1200 matches similar to: "[RFC PATCH] vhost, mm: make sure that oom_reaper doesn't reap memory read by vhost"
2016 Jun 18
0
[RFC PATCH] vhost, mm: make sure that oom_reaper doesn't reap memory read by vhost
On Fri, Jun 17, 2016 at 11:00:17AM +0200, Michal Hocko wrote:
> From: Michal Hocko <mhocko at suse.com>
>
> vhost driver relies on copy_from_user/get_user from a kernel thread.
> This makes it impossible to reap the memory of an oom victim which
> shares mm with the vhost kernel thread because it could see a zero
> page unexpectedly and theoretically make an incorrect
2016 Jun 19
2
[RFC PATCH] vhost, mm: make sure that oom_reaper doesn't reap memory read by vhost
On Sat 18-06-16 03:09:02, Michael S. Tsirkin wrote:
> On Fri, Jun 17, 2016 at 11:00:17AM +0200, Michal Hocko wrote:
[...]
> > It seems that vhost usage would suffer from this problem because
> > it reads from the userspace to get (status) flags and makes some
> > decisions based on the read value. I do not understand the code so I
> > couldn't evaluate whether that
2016 Jun 19
2
[RFC PATCH] vhost, mm: make sure that oom_reaper doesn't reap memory read by vhost
On Sat 18-06-16 03:09:02, Michael S. Tsirkin wrote:
> On Fri, Jun 17, 2016 at 11:00:17AM +0200, Michal Hocko wrote:
[...]
> > It seems that vhost usage would suffer from this problem because
> > it reads from the userspace to get (status) flags and makes some
> > decisions based on the read value. I do not understand the code so I
> > couldn't evaluate whether that
2019 Sep 06
0
possible deadlock in __mmu_notifier_invalidate_range_end
Hello,
syzbot found the following crash on:
HEAD commit: 6d028043 Add linux-next specific files for 20190830
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=16cbf22a600000
kernel config: https://syzkaller.appspot.com/x/.config?x=82a6bec43ab0cb69
dashboard link: https://syzkaller.appspot.com/bug?extid=aaedc50d99a03250fe1f
compiler: gcc (GCC) 9.0.0
2020 Apr 04
14
improve use_mm / unuse_mm
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.
2020 Apr 04
14
improve use_mm / unuse_mm
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.
2020 Apr 16
8
improve use_mm / unuse_mm v2
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
2020 Apr 16
8
improve use_mm / unuse_mm v2
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
2017 Sep 11
6
mm, virtio: possible OOM lockup at virtballoon_oom_notify()
Hello.
I noticed that virtio_balloon is using register_oom_notifier() and
leak_balloon() from virtballoon_oom_notify() might depend on
__GFP_DIRECT_RECLAIM memory allocation.
In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to
serialize against fill_balloon(). But in fill_balloon(),
alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) is
called with
2017 Sep 11
6
mm, virtio: possible OOM lockup at virtballoon_oom_notify()
Hello.
I noticed that virtio_balloon is using register_oom_notifier() and
leak_balloon() from virtballoon_oom_notify() might depend on
__GFP_DIRECT_RECLAIM memory allocation.
In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to
serialize against fill_balloon(). But in fill_balloon(),
alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) is
called with
2019 Jan 25
0
[klibc:update-dash] eval: Reap zombies after built-in commands and functions
Commit-ID: ed1a1311732c764495a5ec26bfdcac34ea6dce1b
Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=ed1a1311732c764495a5ec26bfdcac34ea6dce1b
Author: Herbert Xu <herbert at gondor.apana.org.au>
AuthorDate: Mon, 26 Mar 2018 23:55:50 +0800
Committer: Ben Hutchings <ben at decadent.org.uk>
CommitDate: Fri, 25 Jan 2019 02:57:21 +0000
[klibc] eval: Reap zombies
2020 Mar 28
0
[klibc:update-dash] dash: eval: Reap zombies after built-in commands and functions
Commit-ID: a33ea92e57007317a5c406626441029899e164e0
Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=a33ea92e57007317a5c406626441029899e164e0
Author: Herbert Xu <herbert at gondor.apana.org.au>
AuthorDate: Mon, 26 Mar 2018 23:55:50 +0800
Committer: Ben Hutchings <ben at decadent.org.uk>
CommitDate: Sat, 28 Mar 2020 21:42:54 +0000
[klibc] dash: eval: Reap
2010 May 05
1
[PATCH 1/2] reap the blktapctl thread and notify the tapdisk backend driver to release resource like memory..
Hi,
For this issue I had initial discussion thread before, more detail, please see :
http://lists.xensource.com/archives/html/xen-devel/2010-04/msg01140.html.
I write a new patch for this issue, which modified qemu code. So Ian, could you take a look this patch,too.
thanks,
James (Song Wei)
Signed-off-by: James ( Song Wei ) <jsong@novell.com>
diff -r efa1b905d893
2023 Jul 27
1
High memory consumption for small AXFR
Hello!
I use NSD 4.7.0 self compiled:
Configure line: --build=x86_64-linux-gnu --prefix=/usr --includedir=${prefix}/include --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-option-checking --disable-silent-rules --libdir=${prefix}/lib/x86_64-linux-gnu --runstatedir=/run --disable-maintainer-mode --disable-dependency-tracking
2008 May 25
19
[Bug 1470] New: adjust Linux out-of-memory killer to stop sshd being killed
https://bugzilla.mindrot.org/show_bug.cgi?id=1470
Summary: adjust Linux out-of-memory killer to stop sshd being
killed
Classification: Unclassified
Product: Portable OpenSSH
Version: 5.0p1
Platform: All
URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=34176
7
OS/Version: Linux
2004 Dec 28
4
error: (XEN) Not enough memory for DOM0 memory reservation.
Dear list,
I''m trying to get Xen working on a P3-600E with 320 MB RAM. (256+64)
It has suse linux 9.1 installed on it, and I tried to get xen running with
both the binary download from the xen pages and the suse xen packages
mentioned on this list some days ago.
Both ''install packages/kernels'' lead to the same error:
(XEN) Not enough memory for DOM0 memory
2014 Nov 24
2
[PATCH v3 26/41] vhost: virtio 1.0 endian-ness support
Signed-off-by: Michael S. Tsirkin <mst at redhat.com>
---
drivers/vhost/vhost.c | 93 +++++++++++++++++++++++++++++++--------------------
1 file changed, 56 insertions(+), 37 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index c90f437..4d379ed 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -33,8 +33,8 @@ enum {
VHOST_MEMORY_F_LOG = 0x1,
};
2014 Nov 24
2
[PATCH v3 26/41] vhost: virtio 1.0 endian-ness support
Signed-off-by: Michael S. Tsirkin <mst at redhat.com>
---
drivers/vhost/vhost.c | 93 +++++++++++++++++++++++++++++++--------------------
1 file changed, 56 insertions(+), 37 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index c90f437..4d379ed 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -33,8 +33,8 @@ enum {
VHOST_MEMORY_F_LOG = 0x1,
};
2019 Jul 12
2
Out of memory: kill process
Hello,
On my bridge head DC, i can see in kern.log lots of < Out of memory : kill process >
I'm using Samba 4.9.6 (11147 objects) on Debian Stretch 64
This DC synchronize from/to 20 others DC in bridge head mode (no mesh)
Here is my VM (HyperV 2016) config :
- 4 x Vcpu (intel Xeon Silver 4110)
- 2 Go Ram
- 1 Go swap
I'm really not an expert on this
2020 Apr 04
0
[PATCH 5/6] kernel: better document the use_mm/unuse_mm API contract
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 +--