> -----Original Message----- > From: Christoph Hellwig [mailto:hch@xxxxxxxxxxxxx] > Sent: Monday, September 18, 2017 9:52 PM > To: Shivasharan Srikanteshwara > Cc: Christoph Hellwig; shuwang@xxxxxxxxxx; Kashyap Desai; Sumit Saxena; > jejb@xxxxxxxxxxxxxxxxxx; martin.petersen@xxxxxxxxxx; > PDL,MEGARAIDLINUX; linux-scsi@xxxxxxxxxxxxxxx; linux- > kernel@xxxxxxxxxxxxxxx; chuhu@xxxxxxxxxx; yizhan@xxxxxxxxxx; > catalin.marinas@xxxxxxx > 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