Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933489AbdIYIss (ORCPT ); Mon, 25 Sep 2017 04:48:48 -0400 Received: from mail-wr0-f171.google.com ([209.85.128.171]:44709 "EHLO mail-wr0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933062AbdIYIsp (ORCPT ); Mon, 25 Sep 2017 04:48:45 -0400 X-Google-Smtp-Source: AOwi7QCTD3E0moq1rl/vzJDlQhaQ3LegkoJ1Q12nBR3ZZiS5SsnIbibmgZq/HseXsDNes/68GLtXgJLKWKexD9HE0qw= From: Shivasharan Srikanteshwara References: <20170915052152.5032-1-shuwang@redhat.com> <20170915180007.GA24045@infradead.org> <20170918162135.GA20366@infradead.org> In-Reply-To: <20170918162135.GA20366@infradead.org> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK5nzRF8UstAK9FYuu6wfWCRpZy4gIu8KhlAXfEFz8CtwZTk6DFe++g Date: Mon, 25 Sep 2017 13:38:23 +0530 Message-ID: Subject: RE: [PATCH V2] megaraid: kmemleak: Track page allocation for fusion To: Christoph Hellwig Cc: shuwang@redhat.com, Kashyap Desai , Sumit Saxena , jejb@linux.vnet.ibm.com, martin.petersen@oracle.com, "PDL,MEGARAIDLINUX" , linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, chuhu@redhat.com, yizhan@redhat.com, catalin.marinas@arm.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1502 Lines: 37 > -----Original Message----- > From: Christoph Hellwig [mailto:hch@infradead.org] > Sent: Monday, September 18, 2017 9:52 PM > To: Shivasharan Srikanteshwara > Cc: Christoph Hellwig; shuwang@redhat.com; Kashyap Desai; Sumit Saxena; > jejb@linux.vnet.ibm.com; martin.petersen@oracle.com; > PDL,MEGARAIDLINUX; 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 > > Oh, I missed log_to_span. Well, in that case log_to_span is _the_ candidate > for moving into a separate allocation. > > And in fact you're probably better off by using a sensible data structure for it, > e.g. a radix tree. Thanks Christoph. We will make the changes suggested in phased approach. First we will fix kmemleak false positives by moving log_to_span allocation separate from fusion_context. The data structure change would involve major changes which affects IO path as well. Also driver expects log_to_span and other data structures to be available at load time itself. Considering this, we need to understand if radix tree would be a good choice for the change. Based on internal discussions, we see other similar arrays in driver code that we can change similarly eg. load_balance_info. This is definitely something to add to our to-do lists. These changes need to go through our internal regression test cycle and then submit it to upstream. Best regards, Shivasharan