All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Arend van Spriel <arend.vanspriel@broadcom.com>
Cc: backports@vger.kernel.org
Subject: Re: [PATCH] patches: add patch for compat/lib-rhashtable.c
Date: Tue, 30 May 2017 09:19:03 +0200	[thread overview]
Message-ID: <1496128743.3327.1.camel@sipsolutions.net> (raw)
In-Reply-To: <0c32b99a-63c4-476c-85f2-67e63d4219bc@broadcom.com> (sfid-20170524_213651_376796_A77DF7BA)

On Wed, 2017-05-24 at 21:36 +0200, Arend van Spriel wrote:

> > 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.

Huh, ok, that's a good point. I guess I'll take this for now.

johannes
--
To unsubscribe from this list: send the line "unsubscribe backports" in

      reply	other threads:[~2017-05-30  7:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-19 20:46 [PATCH] patches: add patch for compat/lib-rhashtable.c Arend van Spriel
2017-05-24  6:46 ` Johannes Berg
2017-05-24 19:36   ` Arend van Spriel
2017-05-30  7:19     ` Johannes Berg [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1496128743.3327.1.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=arend.vanspriel@broadcom.com \
    --cc=backports@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.