search for: out_of_memory

...ecified, this allocation attempt might indirectly depend on somebody > else's __GFP_DIRECT_RECLAIM memory allocation. And such indirect > __GFP_DIRECT_RECLAIM memory allocation might call leak_balloon() via > virtballoon_oom_notify() via blocking_notifier_call_chain() callback via > out_of_memory() when it reached __alloc_pages_may_oom() and held oom_lock > mutex. Since vb->balloon_lock mutex is already held by fill_balloon(), it > will cause OOM lockup. Thus, do not wait for vb->balloon_lock mutex if > leak_balloon() is called from out_of_memory(). > > Thread1...

...ecified, this allocation attempt might indirectly depend on somebody > else's __GFP_DIRECT_RECLAIM memory allocation. And such indirect > __GFP_DIRECT_RECLAIM memory allocation might call leak_balloon() via > virtballoon_oom_notify() via blocking_notifier_call_chain() callback via > out_of_memory() when it reached __alloc_pages_may_oom() and held oom_lock > mutex. Since vb->balloon_lock mutex is already held by fill_balloon(), it > will cause OOM lockup. Thus, do not wait for vb->balloon_lock mutex if > leak_balloon() is called from out_of_memory(). > > Thread1...

...tion attempt might indirectly depend on somebody > > else's __GFP_DIRECT_RECLAIM memory allocation. And such indirect > > __GFP_DIRECT_RECLAIM memory allocation might call leak_balloon() via > > virtballoon_oom_notify() via blocking_notifier_call_chain() callback via > > out_of_memory() when it reached __alloc_pages_may_oom() and held oom_lock > > mutex. Since vb->balloon_lock mutex is already held by fill_balloon(), it > > will cause OOM lockup. Thus, do not wait for vb->balloon_lock mutex if > > leak_balloon() is called from out_of_memory(). > >...

...ndirectly depend on somebody > > > else's __GFP_DIRECT_RECLAIM memory allocation. And such indirect > > > __GFP_DIRECT_RECLAIM memory allocation might call leak_balloon() via > > > virtballoon_oom_notify() via blocking_notifier_call_chain() callback via > > > out_of_memory() when it reached __alloc_pages_may_oom() and held oom_lock > > > mutex. Since vb->balloon_lock mutex is already held by fill_balloon(), it > > > will cause OOM lockup. Thus, do not wait for vb->balloon_lock mutex if > > > leak_balloon() is called from out_of_memory...

...ndirectly depend on somebody > > > else's __GFP_DIRECT_RECLAIM memory allocation. And such indirect > > > __GFP_DIRECT_RECLAIM memory allocation might call leak_balloon() via > > > virtballoon_oom_notify() via blocking_notifier_call_chain() callback via > > > out_of_memory() when it reached __alloc_pages_may_oom() and held oom_lock > > > mutex. Since vb->balloon_lock mutex is already held by fill_balloon(), it > > > will cause OOM lockup. Thus, do not wait for vb->balloon_lock mutex if > > > leak_balloon() is called from out_of_memory...

https://bugzilla.samba.org/show_bug.cgi?id=13433 Bug ID: 13433 Summary: out_of_memory in receive_sums on large files Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: core Assignee: wayned at samba.org Reporter: toasty at...

..._MOVABLE] implies __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, this allocation attempt might depend on somebody else's __GFP_DIRECT_RECLAIM | !__GFP_NORETRY memory allocation. Such __GFP_DIRECT_RECLAIM | !__GFP_NORETRY allocation can reach __alloc_pages_may_oom() and hold oom_lock mutex and call out_of_memory(). And leak_balloon() is called by virtballoon_oom_notify() via blocking_notifier_call_chain() callback when vb->balloon_lock mutex is already held by fill_balloon(). As a result, despite __GFP_NORETRY is specified, fill_balloon() can indirectly get stuck waiting for vb->balloon_lock mutex at...

..._MOVABLE] implies __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, this allocation attempt might depend on somebody else's __GFP_DIRECT_RECLAIM | !__GFP_NORETRY memory allocation. Such __GFP_DIRECT_RECLAIM | !__GFP_NORETRY allocation can reach __alloc_pages_may_oom() and hold oom_lock mutex and call out_of_memory(). And leak_balloon() is called by virtballoon_oom_notify() via blocking_notifier_call_chain() callback when vb->balloon_lock mutex is already held by fill_balloon(). As a result, despite __GFP_NORETRY is specified, fill_balloon() can indirectly get stuck waiting for vb->balloon_lock mutex at...

...tion could benefit the system as a whole. > > > > I might be misunderstanding the meaning of the relevant GFP flags, > > pls correct me if I'm wrong. > > Would you answer to below question by "yes"/"no" ? > > If leak_balloon() is called via out_of_memory(), leak_balloon() > will decrease "struct virtio_balloon"->num_pages. > But, is "struct virtio_balloon_config"->num_pages updated when > leak_balloon() is called via out_of_memory() ? > > Below explanation assumes that your answer is "no". &...

...tion could benefit the system as a whole. > > > > I might be misunderstanding the meaning of the relevant GFP flags, > > pls correct me if I'm wrong. > > Would you answer to below question by "yes"/"no" ? > > If leak_balloon() is called via out_of_memory(), leak_balloon() > will decrease "struct virtio_balloon"->num_pages. > But, is "struct virtio_balloon_config"->num_pages updated when > leak_balloon() is called via out_of_memory() ? > > Below explanation assumes that your answer is "no". &...

...OOM lockup. It turned out that the reason of being unable to login via ssh was that fork() was failing because __vm_enough_memory() was failing because /proc/sys/vm/overcommit_memory was set to 0. Although virtio_balloon driver was ready to release pages if asked via virtballoon_oom_notify() from out_of_memory(), __vm_enough_memory() was not able to take such pages into account. As a result, operations which need to use fork() were failing without calling out_of_memory(). ( http://lkml.kernel.org/r/201710181954.FHH51594.MtFOFLOQFSOHVJ at I-love.SAKURA.ne.jp ) Do you see anything wrong with the patch I u...

...OOM lockup. It turned out that the reason of being unable to login via ssh was that fork() was failing because __vm_enough_memory() was failing because /proc/sys/vm/overcommit_memory was set to 0. Although virtio_balloon driver was ready to release pages if asked via virtballoon_oom_notify() from out_of_memory(), __vm_enough_memory() was not able to take such pages into account. As a result, operations which need to use fork() were failing without calling out_of_memory(). ( http://lkml.kernel.org/r/201710181954.FHH51594.MtFOFLOQFSOHVJ at I-love.SAKURA.ne.jp ) Do you see anything wrong with the patch I u...

...ned out that the reason of being unable to login via ssh was that fork() > was failing because __vm_enough_memory() was failing because > /proc/sys/vm/overcommit_memory was set to 0. Although virtio_balloon driver > was ready to release pages if asked via virtballoon_oom_notify() from > out_of_memory(), __vm_enough_memory() was not able to take such pages into > account. As a result, operations which need to use fork() were failing without > calling out_of_memory(). > ( http://lkml.kernel.org/r/201710181954.FHH51594.MtFOFLOQFSOHVJ at I-love.SAKURA.ne.jp ) > > Do you see anything...

...whole. > > > > > > I might be misunderstanding the meaning of the relevant GFP flags, > > > pls correct me if I'm wrong. > > > > Would you answer to below question by "yes"/"no" ? > > > > If leak_balloon() is called via out_of_memory(), leak_balloon() > > will decrease "struct virtio_balloon"->num_pages. > > But, is "struct virtio_balloon_config"->num_pages updated when > > leak_balloon() is called via out_of_memory() ? > > > > Below explanation assumes that your an...

...t; - mutex_unlock(&vb->balloon_lock); > + if (num_pfns != 0) > + tell_host(vb, vb->inflate_vq, pfns, num_pfns); > + mutex_unlock(&vb->inflate_lock); > + atomic64_add(num_pfns, &vb->num_pages); Isn't this addition too late? If leak_balloon() is called due to out_of_memory(), it will fail to find up to dated vb->num_pages value. > > - return num_allocated_pages; > + return num_pfns; > } > > static void release_pages_balloon(struct virtio_balloon *vb, > @@ -194,38 +192,39 @@ static void release_pages_balloon(struct virtio_balloon *vb, &g...

...t; - mutex_unlock(&vb->balloon_lock); > + if (num_pfns != 0) > + tell_host(vb, vb->inflate_vq, pfns, num_pfns); > + mutex_unlock(&vb->inflate_lock); > + atomic64_add(num_pfns, &vb->num_pages); Isn't this addition too late? If leak_balloon() is called due to out_of_memory(), it will fail to find up to dated vb->num_pages value. > > - return num_allocated_pages; > + return num_pfns; > } > > static void release_pages_balloon(struct virtio_balloon *vb, > @@ -194,38 +192,39 @@ static void release_pages_balloon(struct virtio_balloon *vb, &g...

...; diff -rupNP --exclude-from cvs/.ignore cvs/batch.c pool2/batch.c --- cvs/batch.c Thu Feb 5 20:47:31 2004 +++ pool2/batch.c Thu Feb 5 20:51:14 2004 @@ -136,9 +136,7 @@ struct file_list *create_flist_from_batc exit_cleanup(1); } - batch_flist = new(struct file_list); - if (!batch_flist) - out_of_memory("create_flist_from_batch"); + batch_flist = flist_new(WITH_HLINK, "create_flist_from_batch"); save_read = stats.total_read; save_pv = protocol_version; @@ -153,9 +151,9 @@ struct file_list *create_flist_from_batc for (i = 0; (flags = read_byte(f)) != 0; i++) { if (pro...

..., this allocation attempt might > > > > depend on somebody else's __GFP_DIRECT_RECLAIM | !__GFP_NORETRY memory > > > > allocation. Such __GFP_DIRECT_RECLAIM | !__GFP_NORETRY allocation can reach > > > > __alloc_pages_may_oom() and hold oom_lock mutex and call out_of_memory(). > > > > And leak_balloon() is called by virtballoon_oom_notify() via > > > > blocking_notifier_call_chain() callback when vb->balloon_lock mutex is already > > > > held by fill_balloon(). As a result, despite __GFP_NORETRY is specified, > > > >...

...->balloon_lock); >> + if (num_pfns != 0) >> + tell_host(vb, vb->inflate_vq, pfns, num_pfns); >> + mutex_unlock(&vb->inflate_lock); >> + atomic64_add(num_pfns, &vb->num_pages); > Isn't this addition too late? If leak_balloon() is called due to > out_of_memory(), it will fail to find up to dated vb->num_pages value. Not really. I think the old way of implementation above: "vb->num_pages += VIRTIO_BALLOON_PAGES_PER_PAGE" isn't quite accurate, because "vb->num_page" should reflect the number of pages that have already been...

...__GFP_NORETRY is specified, this allocation attempt might indirectly depend on somebody else's __GFP_DIRECT_RECLAIM memory allocation. And such indirect __GFP_DIRECT_RECLAIM memory allocation might call leak_balloon() via virtballoon_oom_notify() via blocking_notifier_call_chain() callback via out_of_memory() when it reached __alloc_pages_may_oom() and held oom_lock mutex. Since vb->balloon_lock mutex is already held by fill_balloon(), it will cause OOM lockup. Thus, do not wait for vb->balloon_lock mutex if leak_balloon() is called from out_of_memory(). Thread1...