All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tadeusz Struk <tadeusz.struk@linaro.org>
To: patchwork-bot+netdevbpf@kernel.org,
	"David S. Miller" <davem@davemloft.net>
Cc: jmaloy@redhat.com, ying.xue@windriver.com, davem@davemloft.net,
	kuba@kernel.org, netdev@vger.kernel.org,
	tipc-discussion@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] tipc: use consistent GFP flags
Date: Tue, 16 Nov 2021 08:40:49 -0800	[thread overview]
Message-ID: <a0baf2b6-70f9-3185-cd92-d83533c63ff0@linaro.org> (raw)
In-Reply-To: <163698120846.10163.14371622974741533436.git-patchwork-notify@kernel.org>

On 11/15/21 05:00, patchwork-bot+netdevbpf@kernel.org wrote:
> This patch was applied to netdev/net.git (master)
> by David S. Miller<davem@davemloft.net>:
> 
> On Thu, 11 Nov 2021 12:59:16 -0800 you wrote:
>> Some functions, like tipc_crypto_start use inconsisten GFP flags
>> when allocating memory. The mentioned function use GFP_ATOMIC to
>> to alloc a crypto instance, and then calls alloc_ordered_workqueue()
>> which allocates memory with GFP_KERNEL. tipc_aead_init() function
>> even uses GFP_KERNEL and GFP_ATOMIC interchangeably.
>> No doc comment specifies what context a function is designed to
>> work in, but the flags should at least be consistent within a function.
>>
>> [...]
> Here is the summary with links:
>    - tipc: use consistent GFP flags
>      https://git.kernel.org/netdev/net/c/86c3a3e964d9
> 
> You are awesome, thank you!

Thanks, you are awesome too! ;)
Any feedback about the patch:
[PATCH v2] tipc: check for null after calling kmemdup

-- 
Thanks,
Tadeusz

  reply	other threads:[~2021-11-16 16:40 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-11 20:59 [PATCH] tipc: check for null after calling kmemdup Tadeusz Struk
2021-11-11 20:59 ` [PATCH] tipc: use consistent GFP flags Tadeusz Struk
2021-11-15 13:00   ` patchwork-bot+netdevbpf
2021-11-16 16:40     ` Tadeusz Struk [this message]
2021-11-12  0:06 ` [PATCH] tipc: check for null after calling kmemdup Jon Maloy
2021-11-13  4:13   ` Jakub Kicinski
2021-11-13  5:42     ` Tadeusz Struk
2021-11-16 19:32       ` Jakub Kicinski
2021-11-16 19:33         ` Jakub Kicinski
2021-11-13  4:08 ` Jakub Kicinski

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=a0baf2b6-70f9-3185-cd92-d83533c63ff0@linaro.org \
    --to=tadeusz.struk@linaro.org \
    --cc=davem@davemloft.net \
    --cc=jmaloy@redhat.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=patchwork-bot+netdevbpf@kernel.org \
    --cc=tipc-discussion@lists.sourceforge.net \
    --cc=ying.xue@windriver.com \
    /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.