search for: _movable

Displaying 20 results from an estimated 30 matches for "_movable".

Did you mean: movable
mm, virtio: possible OOM lockup at virtballoon_oom_notify()
2017 Sep 11
6
mm, virtio: possible OOM lockup at virtballoon_oom_notify()
...n 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 vb->balloon_lock mutex held. Since GFP_HIGHUSER[_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...
mm, virtio: possible OOM lockup at virtballoon_oom_notify()
2017 Sep 11
6
mm, virtio: possible OOM lockup at virtballoon_oom_notify()
...n 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 vb->balloon_lock mutex held. Since GFP_HIGHUSER[_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...
[PATCH] virtio: avoid possible OOM lockup at virtballoon_oom_notify()
2017 Oct 13
2
[PATCH] virtio: avoid possible OOM lockup at virtballoon_oom_notify()
On Tue, Oct 10, 2017 at 07:47:37PM +0900, Tetsuo Handa wrote: > 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 vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] > implies __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, despite __GFP_NORETRY > is specified, this allocation attempt might indirectly depend on somebody > else's __GFP_D...
[PATCH] virtio: avoid possible OOM lockup at virtballoon_oom_notify()
2017 Oct 13
2
[PATCH] virtio: avoid possible OOM lockup at virtballoon_oom_notify()
On Tue, Oct 10, 2017 at 07:47:37PM +0900, Tetsuo Handa wrote: > 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 vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] > implies __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, despite __GFP_NORETRY > is specified, this allocation attempt might indirectly depend on somebody > else's __GFP_D...
[PATCH] virtio_balloon: fix deadlock on OOM
2017 Oct 13
4
[PATCH] virtio_balloon: fix deadlock on OOM
...ix, 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 against fill_balloon(). But in fill_balloon(), alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) is called with vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] implies __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, despite __GFP_NORETRY is specified, this allocation attempt might indirectly depend on somebody else's __GFP_DIRECT_RECLAIM memory...
[PATCH] virtio_balloon: fix deadlock on OOM
2017 Oct 13
4
[PATCH] virtio_balloon: fix deadlock on OOM
...ix, 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 against fill_balloon(). But in fill_balloon(), alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) is called with vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] implies __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, despite __GFP_NORETRY is specified, this allocation attempt might indirectly depend on somebody else's __GFP_DIRECT_RECLAIM memory...
mm, virtio: possible OOM lockup at virtballoon_oom_notify()
2017 Sep 29
0
mm, virtio: possible OOM lockup at virtballoon_oom_notify()
...er() 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 vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] implies > __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, this allocation attempt might > depend on somebody else's __GFP_DIRECT_RECLAIM | !__GFP_NORETRY memory > allocatio...
[RFC] [PATCH] mm,oom: Offload OOM notify callback to a kernel thread.
2017 Oct 02
0
[RFC] [PATCH] mm,oom: Offload OOM notify callback to a kernel thread.
...> > > > > > > > > > > > > > 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 vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] implies > > > > > > > __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, this allocation attempt might > > > > > > >...
[PATCH v3] virtio_balloon: fix deadlock on OOM
2017 Nov 08
2
[PATCH v3] virtio_balloon: fix deadlock on OOM
...ix, 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 against fill_balloon(). But in fill_balloon(), alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) is called with vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] implies __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, despite __GFP_NORETRY is specified, this allocation attempt might indirectly depend on somebody else's __GFP_DIRECT_RECLAIM memory...
[PATCH v3] virtio_balloon: fix deadlock on OOM
2017 Nov 08
2
[PATCH v3] virtio_balloon: fix deadlock on OOM
...ix, 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 against fill_balloon(). But in fill_balloon(), alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) is called with vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] implies __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, despite __GFP_NORETRY is specified, this allocation attempt might indirectly depend on somebody else's __GFP_DIRECT_RECLAIM memory...
[PATCH] virtio: avoid possible OOM lockup at virtballoon_oom_notify()
2017 Oct 10
0
[PATCH] virtio: avoid possible OOM lockup at virtballoon_oom_notify()
On Tue 10-10-17 19:47:37, Tetsuo Handa wrote: > 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 vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] > implies __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, despite __GFP_NORETRY > is specified, this allocation attempt might indirectly depend on somebody > else's __GFP_D...
[PATCH] virtio: avoid possible OOM lockup at virtballoon_oom_notify()
2017 Oct 12
0
[PATCH] virtio: avoid possible OOM lockup at virtballoon_oom_notify()
On 10/10/2017 06:47 PM, Tetsuo Handa wrote: > 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 vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] > implies __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, despite __GFP_NORETRY > is specified, this allocation attempt might indirectly depend on somebody > else's __GFP_D...
[PATCH] virtio: avoid possible OOM lockup at virtballoon_oom_notify()
2017 Oct 10
0
[PATCH] virtio: avoid possible OOM lockup at virtballoon_oom_notify()
On Tue 10-10-17 19:47:37, Tetsuo Handa wrote: > 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 vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] > implies __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, despite __GFP_NORETRY > is specified, this allocation attempt might indirectly depend on somebody > else's __GFP_D...
[PATCH] virtio: avoid possible OOM lockup at virtballoon_oom_notify()
2017 Oct 12
0
[PATCH] virtio: avoid possible OOM lockup at virtballoon_oom_notify()
On 10/10/2017 06:47 PM, Tetsuo Handa wrote: > 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 vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] > implies __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, despite __GFP_NORETRY > is specified, this allocation attempt might indirectly depend on somebody > else's __GFP_D...
[PATCH] virtio: avoid possible OOM lockup at virtballoon_oom_notify()
2017 Oct 13
0
[PATCH] virtio: avoid possible OOM lockup at virtballoon_oom_notify()
...te: Tue, 10 Oct 2017 19:28:20 +0900 > Subject: [PATCH] virtio: avoid possible OOM lockup at virtballoon_oom_notify() > > 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 vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] > implies __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, despite __GFP_NORETRY > is specified, this allocation attempt might indirectly depend on somebody > else's __GFP_D...
[PATCH] virtio: avoid possible OOM lockup at virtballoon_oom_notify()
2017 Oct 13
0
[PATCH] virtio: avoid possible OOM lockup at virtballoon_oom_notify()
...te: Tue, 10 Oct 2017 19:28:20 +0900 > Subject: [PATCH] virtio: avoid possible OOM lockup at virtballoon_oom_notify() > > 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 vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] > implies __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, despite __GFP_NORETRY > is specified, this allocation attempt might indirectly depend on somebody > else's __GFP_D...
[PATCH] virtio: avoid possible OOM lockup at virtballoon_oom_notify()
2017 Oct 13
0
[PATCH] virtio: avoid possible OOM lockup at virtballoon_oom_notify()
Michael S. Tsirkin wrote: > On Tue, Oct 10, 2017 at 07:47:37PM +0900, Tetsuo Handa wrote: > > 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 vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] > > implies __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, despite __GFP_NORETRY > > is specified, this allocation attempt might indirectly depend on somebody > &gt...
[RFC] [PATCH] mm,oom: Offload OOM notify callback to a kernel thread.
2017 Oct 02
2
[RFC] [PATCH] mm,oom: Offload OOM notify callback to a kernel thread.
...> > > > > > > > > > > > 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 vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] implies > > > > > > > > __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, this allocation attempt might > > > > >...
[RFC] [PATCH] mm,oom: Offload OOM notify callback to a kernel thread.
2017 Oct 02
2
[RFC] [PATCH] mm,oom: Offload OOM notify callback to a kernel thread.
...> > > > > > > > > > > > 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 vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] implies > > > > > > > > __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, this allocation attempt might > > > > >...
[RFC] [PATCH] mm,oom: Offload OOM notify callback to a kernel thread.
2017 Oct 02
0
[RFC] [PATCH] mm,oom: Offload OOM notify callback to a kernel thread.
...> > > > __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 vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] implies > > > > __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, this allocation attempt might > > > > depend on somebody else's __GFP_DIRECT_R...