search for: oom_killer

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

Hi All, I have a server that has its swappiness set to 0. It is running a little tight on memory and so there have been a couple of events where the OOM_killer has been invoked and killed off MySQL, which you would expect. Now if you have your swappiness at 0 then "A value of 0 instructs the kernel not to initiate swap until the amount of free and file-backed pages is less than the high water mark in a zone."[1] So even in this event should I...

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 decision visible outside of the killed task context. Make sure that each place which can read

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 decision visible outside of the killed task context. Make sure that each place which can read

...EXPORT_SYMBOL_GPL(register_oom_notifier); > @@ -1005,17 +1033,21 @@ int unregister_oom_notifier(struct notifier_block *nb) > */ > bool out_of_memory(struct oom_control *oc) > { > - unsigned long freed = 0; > enum oom_constraint constraint = CONSTRAINT_NONE; > > if (oom_killer_disabled) > return false; > > - if (!is_memcg_oom(oc)) { > - blocking_notifier_call_chain(&oom_notify_list, 0, &freed); > - if (freed > 0) > + if (!is_memcg_oom(oc) && oom_notifier_th) { > + oom_notifier_requested = true; > + wake_up(&oom_noti...

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

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

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

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

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

...tPractices cheers -henrik On Fri, Feb 11, 2011 at 02:18:48PM +0300, George Shuklin wrote: > Yes, swap is almost mandatory - it will save machine from state ''very > low mem''. From my research (mostly on XCP) this state may cause > unstability for some kernels, causing OOM_killer to kill many processes > (sometimes including init - means kernel panic). Swap reducing chances > to get to this state. > > Second very important point: ballooning. When ballooning (inflating > balloon = reduce mem) occur, if kernel have no free address space it can > invoke...

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

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

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.

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

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

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

On 09/16/2015 09:11 AM, Callum Scott wrote: > It is running a little > tight on memory and so there have been a couple of events where the > OOM_killer has been invoked and killed off MySQL, which you would expect. One thing that should be noted is that regardless of swappiness, overcommit might be an issue. If a single process is using most of the memory in a system, and attempts to fork(), as it will if it calls system(), then the system ma...