> -----Original Message----- > From: Christoph Hellwig [mailto:h...@infradead.org] > Sent: Monday, September 18, 2017 9:52 PM > To: Shivasharan Srikanteshwara > Cc: Christoph Hellwig; shuw...@redhat.com; Kashyap Desai; Sumit Saxena; > j...@linux.vnet.ibm.com; martin.peter...@oracle.com; > PDL,MEGARAIDLINUX; linux-scsi@vger.kernel.org; linux- > ker...@vger.kernel.org; ch...@redhat.com; yiz...@redhat.com; > catalin.mari...@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
