[Drbd-dev] [PATCH] drbd: Avoid GFP_KERNEL allocation from alloc_send_buffer()
Tetsuo Handa
penguin-kernel at i-love.sakura.ne.jp
Thu Apr 25 13:23:55 CEST 2019
On 2019/04/25 20:02, Roland Kammerer wrote:
> On Thu, Apr 25, 2019 at 12:43:21PM +0200, Roland Kammerer wrote:
>> On Thu, Apr 25, 2019 at 06:29:11PM +0900, Tetsuo Handa wrote:
>>> drbd/drbd_main.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drbd/drbd_main.c b/drbd/drbd_main.c
>>> index 80afdd8a..d48a5ea3 100644
>>> --- a/drbd/drbd_main.c
>>> +++ b/drbd/drbd_main.c
>>> @@ -966,7 +966,7 @@ static void new_or_recycle_send_buffer_page(struct drbd_send_buffer *sbuf)
>>> if (count == 1)
>>> goto have_page;
>>>
>>> - page = alloc_page(GFP_KERNEL);
>>> + page = alloc_page(GFP_ATOMIC);
>>> if (page) {
>>> put_page(sbuf->page);
>>> sbuf->page = page;
>>
>> Thanks for reporting and a proposed fix. By coincidence this was already
>> fixed by Phil in our internal tree like this:
OK.
>>
>>> - page = alloc_page(GFP_KERNEL);
>>> + page = alloc_page(GFP_NOIP | __GFP_NOWARN);
>
> And that is what you get when you type instead of copy/paste... This is
> the correcte one:
>
> - page = alloc_page(GFP_KERNEL);
> + page = alloc_page(GFP_NOIO | __GFP_NOWARN);
Due to 'The "too small to fail" memory-allocation rule'
( https://lwn.net/Articles/627419/ ), I think that this allocation
would loop forever inside the page allocator until somebody volunteers
a page because this is called by a kernel thread which won't be killed
by the OOM killer. That is, __GFP_NOWARN unlikely makes sense.
What happens if nobody volunteers a page when current thread is
calling new_or_recycle_send_buffer_page() ? In other words, may I ask
the reason why GFP_NOIO is safe here?
More information about the drbd-dev
mailing list