[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20150923.153117.2291008783799112683.davem@davemloft.net>
Date: Wed, 23 Sep 2015 15:31:17 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: wangweidong1@...wei.com
Cc: sony.chacko@...gic.com, Dept-HSGLinuxNICDev@...gic.com,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
rui.xiang@...wei.com
Subject: Re: [PATCH net-next] BNX2: fix a Null Pointer for stats_blk
From: Weidong Wang <wangweidong1@...wei.com>
Date: Tue, 22 Sep 2015 20:42:40 +0800
> @@ -880,6 +882,7 @@ bnx2_alloc_mem(struct bnx2 *bp)
> }
> }
>
> + spin_lock(&bp->stats64_lock);
> bp->stats_blk = status_blk + status_blk_size;
>
> bp->stats_blk_mapping = bp->status_blk_mapping + status_blk_size;
> @@ -894,20 +897,23 @@ bnx2_alloc_mem(struct bnx2 *bp)
> &bp->ctx_blk_mapping[i],
> GFP_KERNEL);
> if (bp->ctx_blk[i] == NULL)
> - goto alloc_mem_err;
> + goto free_stats64_lock;
> }
> }
>
> err = bnx2_alloc_rx_mem(bp);
> if (err)
> - goto alloc_mem_err;
> + goto free_stats64_lock;
You're holding a spinlock while doing GFP_KERNEL allocations.
Second of all, taking a spinlock in get_stats64() defeats the whole
intention of making statistics acquisition as fast and as SMP scalable
as possible.
--
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