similar to: [RFC PATCH] vhost, mm: make sure that oom_reaper doesn't reap memory read by vhost

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 +--