[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