From: Masashi Honma <masashi.honma@gmail.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [RFC 5/7] net: Add allocation flag to rtnl_unicast()
Date: Fri, 8 Jul 2016 12:15:35 +0900 [thread overview]
Message-ID: <577F1AD7.8040800@gmail.com> (raw)
In-Reply-To: <1467946591.1273.45.camel@edumazet-glaptop3.roam.corp.google.com>
On 2016?07?08? 11:56, Eric Dumazet wrote:
>
> Managing to mix GFP_ATOMIC and GFP_KERNEL almost randomly as you did in
> this patch is definitely not good.
>
> Further more, RTNL is a mutex, held in control path, designed to allow
> schedules and waiting for memory under pressure.
>
> We do not want to encourage GFP_ATOMIC usage in control path.
>
> Your patch series gives the wrong signal to developers.
>
>
>
Thanks for comment.
I have selected GFP flags based on existing code.
I have selected GFP_ATOMIC in inet6_netconf_get_devconf() because
skb was allocated with GFP_ATOMIC.
I have used GFP_KERNEL in inet6_rtm_getaddr() by same reason.
> I will send a patch against net/ipv4/devinet.c so that we remove
> GFP_ATOMIC usage there.
Thanks. I will modify my patch based on your new code.
WARNING: multiple messages have this Message-ID (diff)
From: Masashi Honma <masashi.honma@gmail.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: netdev@vger.kernel.org, netfilter-devel@vger.kernel.org,
linux-wireless@vger.kernel.org, linux-rdma@vger.kernel.org,
linux-audit@redhat.com, cluster-devel@redhat.com,
davem@davemloft.net, johannes@sipsolutions.net,
pablo@netfilter.org, kaber@trash.net, kadlec@blackhole.kfki.hu,
dledford@redhat.com, sean.hefty@intel.com,
hal.rosenstock@gmail.com, paul@paul-moore.com, eparis@redhat.com,
zbr@ioremap.net, pshelar@nicira.com, ccaulfie@redhat.com,
teigland@redhat.com, bsingharora@gmail.com
Subject: Re: [RFC 5/7] net: Add allocation flag to rtnl_unicast()
Date: Fri, 8 Jul 2016 12:15:35 +0900 [thread overview]
Message-ID: <577F1AD7.8040800@gmail.com> (raw)
In-Reply-To: <1467946591.1273.45.camel@edumazet-glaptop3.roam.corp.google.com>
On 2016年07月08日 11:56, Eric Dumazet wrote:
>
> Managing to mix GFP_ATOMIC and GFP_KERNEL almost randomly as you did in
> this patch is definitely not good.
>
> Further more, RTNL is a mutex, held in control path, designed to allow
> schedules and waiting for memory under pressure.
>
> We do not want to encourage GFP_ATOMIC usage in control path.
>
> Your patch series gives the wrong signal to developers.
>
>
>
Thanks for comment.
I have selected GFP flags based on existing code.
I have selected GFP_ATOMIC in inet6_netconf_get_devconf() because
skb was allocated with GFP_ATOMIC.
I have used GFP_KERNEL in inet6_rtm_getaddr() by same reason.
> I will send a patch against net/ipv4/devinet.c so that we remove
> GFP_ATOMIC usage there.
Thanks. I will modify my patch based on your new code.
next prev parent reply other threads:[~2016-07-08 3:15 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-06 0:28 [Cluster-devel] [RFC 0/7] netlink: Add allocation flag to netlink_unicast() Masashi Honma
2016-07-06 0:28 ` Masashi Honma
2016-07-06 0:28 ` Masashi Honma
2016-07-06 0:28 ` [Cluster-devel] [RFC 1/7] " Masashi Honma
2016-07-06 0:28 ` Masashi Honma
2016-07-06 0:28 ` [Cluster-devel] [RFC 2/7] netfilter: Add allocation flag to nfnetlink_unicast() Masashi Honma
2016-07-06 0:28 ` Masashi Honma
2016-07-06 0:28 ` [Cluster-devel] [RFC 3/7] netlink: Add allocation flag to nlmsg_unicast() Masashi Honma
2016-07-06 0:28 ` Masashi Honma
2016-07-06 0:28 ` Masashi Honma
2016-07-06 0:28 ` [Cluster-devel] [RFC 4/7] infiniband: Add allocation flag to ibnl_unicast() Masashi Honma
2016-07-06 0:28 ` Masashi Honma
2016-07-06 0:28 ` [Cluster-devel] [RFC 5/7] net: Add allocation flag to rtnl_unicast() Masashi Honma
2016-07-06 0:28 ` Masashi Honma
2016-07-08 2:56 ` [Cluster-devel] " Eric Dumazet
2016-07-08 2:56 ` Eric Dumazet
2016-07-08 3:15 ` Masashi Honma [this message]
2016-07-08 3:15 ` Masashi Honma
2016-07-08 4:00 ` [Cluster-devel] " Eric Dumazet
2016-07-08 4:00 ` Eric Dumazet
2016-07-08 4:00 ` Eric Dumazet
2016-07-08 3:18 ` [PATCH net-next] ipv4: do not abuse GFP_ATOMIC in inet_netconf_notify_devconf() Eric Dumazet
2016-07-08 3:46 ` [PATCH net-next] ipv6: do not abuse GFP_ATOMIC in inet6_netconf_notify_devconf() Eric Dumazet
2016-07-08 7:58 ` Nicolas Dichtel
2016-07-09 22:14 ` David Miller
2016-07-08 7:54 ` [PATCH net-next] ipv4: do not abuse GFP_ATOMIC in inet_netconf_notify_devconf() Nicolas Dichtel
2016-07-09 22:12 ` David Miller
2016-07-06 0:28 ` [Cluster-devel] [RFC 6/7] genetlink: Add allocation flag to genlmsg_unicast() Masashi Honma
2016-07-06 0:28 ` Masashi Honma
2016-07-06 0:28 ` Masashi Honma
2016-07-06 0:28 ` [Cluster-devel] [RFC 7/7] genetlink: Add allocation flag to genlmsg_reply() Masashi Honma
2016-07-06 0:28 ` Masashi Honma
2016-07-06 0:28 ` Masashi Honma
2016-07-06 3:22 ` [Cluster-devel] [RFC 0/7] netlink: Add allocation flag to netlink_unicast() David Miller
2016-07-06 3:22 ` David Miller
2016-07-06 3:22 ` David Miller
2016-07-07 0:35 ` [Cluster-devel] " Masashi Honma
2016-07-07 0:35 ` Masashi Honma
[not found] ` <20160708160821.GA2048@redhat.com>
2016-07-09 3:52 ` [Cluster-devel] " Masashi Honma
2016-07-09 3:52 ` Masashi Honma
2016-07-09 3:52 ` Masashi Honma
2016-07-09 3:54 ` [Cluster-devel] " Masashi Honma
2016-07-09 3:54 ` Masashi Honma
2016-07-09 3:54 ` Masashi Honma
2016-07-09 3:59 ` [PATCH v2 net-next] rtnl: Add GFP flag argument to rtnl_unicast() Masashi Honma
2016-07-11 20:01 ` David Miller
2016-07-12 4:23 ` Masashi Honma
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=577F1AD7.8040800@gmail.com \
--to=masashi.honma@gmail.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.