lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Mon, 2 Nov 2015 12:08:24 +0200
From:	Erez Shitrit <erezsh@....mellanox.co.il>
To:	Saurabh Sengar <saurabh.truth@...il.com>
Cc:	sean.hefty@...el.com, hal.rosenstock@...il.com,
	Roland Dreier <roland@...estorage.com>,
	Or Gerlitz <ogerlitz@...lanox.com>,
	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	cl@...ux.com,
	"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] IB/ipoib: optimized the function ipoib_mcast_alloc

On Sun, Nov 1, 2015 at 8:23 AM, Saurabh Sengar <saurabh.truth@...il.com> wrote:
> ipoib_mcast_alloc is called only in atomic context,
> hence removing the extra check.
>
> Signed-off-by: Saurabh Sengar <saurabh.truth@...il.com>

Acked-by: Erez Shitrit <erezsh@...lanox.com>

> ---
> Hi,
> Even if in future, if there are some functions expected to call it in normal context(not atomic),
> we can pass the GFP_KERNEL or GFP_ATOMIC directly to function call instead of passing 0 and 1,
> which later again need to be compared in order to change it to GFP_KERNEL and GFP_ATOMIC.
> Please let me know if there are better ways to improve it.
>
>  drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 11 +++++------
>  1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
> index d750a86..15d35be 100644
> --- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
> +++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
> @@ -132,12 +132,11 @@ void ipoib_mcast_free(struct ipoib_mcast *mcast)
>         kfree(mcast);
>  }
>
> -static struct ipoib_mcast *ipoib_mcast_alloc(struct net_device *dev,
> -                                            int can_sleep)
> +static struct ipoib_mcast *ipoib_mcast_alloc(struct net_device *dev)
>  {
>         struct ipoib_mcast *mcast;
>
> -       mcast = kzalloc(sizeof *mcast, can_sleep ? GFP_KERNEL : GFP_ATOMIC);
> +       mcast = kzalloc(sizeof *mcast, GFP_ATOMIC);
>         if (!mcast)
>                 return NULL;
>
> @@ -573,7 +572,7 @@ void ipoib_mcast_join_task(struct work_struct *work)
>         if (!priv->broadcast) {
>                 struct ipoib_mcast *broadcast;
>
> -               broadcast = ipoib_mcast_alloc(dev, 0);
> +               broadcast = ipoib_mcast_alloc(dev);
>                 if (!broadcast) {
>                         ipoib_warn(priv, "failed to allocate broadcast group\n");
>                         /*
> @@ -728,7 +727,7 @@ void ipoib_mcast_send(struct net_device *dev, u8 *daddr, struct sk_buff *skb)
>                         ipoib_dbg_mcast(priv, "setting up send only multicast group for %pI6\n",
>                                         mgid);
>
> -                       mcast = ipoib_mcast_alloc(dev, 0);
> +                       mcast = ipoib_mcast_alloc(dev);
>                         if (!mcast) {
>                                 ipoib_warn(priv, "unable to allocate memory "
>                                            "for multicast structure\n");
> @@ -886,7 +885,7 @@ void ipoib_mcast_restart_task(struct work_struct *work)
>                         ipoib_dbg_mcast(priv, "adding multicast entry for mgid %pI6\n",
>                                         mgid.raw);
>
> -                       nmcast = ipoib_mcast_alloc(dev, 0);
> +                       nmcast = ipoib_mcast_alloc(dev);
>                         if (!nmcast) {
>                                 ipoib_warn(priv, "unable to allocate memory for multicast structure\n");
>                                 continue;
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ