Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751634AbdIOSAL (ORCPT ); Fri, 15 Sep 2017 14:00:11 -0400 Received: from bombadil.infradead.org ([65.50.211.133]:60770 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751365AbdIOSAK (ORCPT ); Fri, 15 Sep 2017 14:00:10 -0400 Date: Fri, 15 Sep 2017 11:00:07 -0700 From: Christoph Hellwig To: shuwang@redhat.com Cc: kashyap.desai@broadcom.com, sumit.saxena@broadcom.com, shivasharan.srikanteshwara@broadcom.com, jejb@linux.vnet.ibm.com, martin.petersen@oracle.com, megaraidlinux.pdl@broadcom.com, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, chuhu@redhat.com, yizhan@redhat.com, catalin.marinas@arm.com Subject: Re: [PATCH V2] megaraid: kmemleak: Track page allocation for fusion Message-ID: <20170915180007.GA24045@infradead.org> References: <20170915052152.5032-1-shuwang@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170915052152.5032-1-shuwang@redhat.com> User-Agent: Mutt/1.8.3 (2017-05-23) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 305 Lines: 6 I think the megaraid fusion code has a deeper problem here. Instead of playing weird games with get_free_pages and vmalloc the structure just needs to shrink by moving all the arrays of MAX_MSIX_QUEUES_FUSION size into a separate allocation for each, and then we have normall, small kmalloc allocations.