On 24-05-17 08:46, Johannes Berg wrote:
> On Fri, 2017-05-19 at 21:46 +0100, Arend van Spriel wrote:
>> The file compat/lib-rhashtable.c is a copy from the backported kernel
>> source lib/rhashtable.c. This patch reverts a recent change to that
>> file, ie. commit 43ca5bc4f72e ("lib/rhashtable.c: simplify a strange
>> allocation pattern"). It introduced the function
>> gfpflags_allow_blocking()
>> introduced in 4.4 kernel and kvmalloc() introduced in 4.12-rc1.
>> Looking
>> at those functions backporting them is complicated so instead add
>> this
>> patch that reverts the change for kernel prior to 4.12.
>
> Thanks Arend!
>
> Why do you think backporting it is complicated though?
>
> kvmalloc() is just kvmalloc_node(), and if we disregard the
> __vmalloc_node_flags_caller() but - since kvmalloc() doesn't care about
> node anyway - just use __vmalloc() there, it should be easy? The
> pgprot_t argument is just PAGE_KERNEL, and the other stuff doesn't
> really matter.
>
> gfpflags_allow_blocking() is a pretty simple inline, and even if we'd
> implement it to always return false we'd get the old rhashtable
> behaviour.
I was reading commit d0164adc89f6 ("mm, page_alloc: distinguish between
being unable to sleep, unwilling to slee...") which introduced
gfpflags_allow_blocking() and did a lot more stuff. So I could not
really determine the implications of backporting
gfpflags_allow_blocking(). We can indeed probably make it work for
rhashtable easily, but will that be appropriate if some other backport
code starts using it.
Regards,
Arend
--
To unsubscribe from this list: send the line "unsubscribe backports" in
