@oracle.com;
> PDL,MEGARAIDLINUX; linux-s...@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
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.
om;
> martin.peter...@oracle.com; megaraidlinux@broadcom.com; linux-
> s...@vger.kernel.org; linux-kernel@vger.kernel.org; ch...@redhat.com;
> yiz...@redhat.com; catalin.mari...@arm.com
> Subject: Re: [PATCH V2] megaraid: kmemleak: Track page allocation for
fusion
>
> I think t
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 allocat
On Fri, 2017-09-15 at 13:21 +0800, shuw...@redhat.com wrote:
> @@ -4548,9 +4556,11 @@ megasas_free_fusion_context(struct megasas_instance
> *instance)
>
> if (is_vmalloc_addr(fusion))
> vfree(fusion);
> - else
> + else {
> +
On Fri, Sep 15, 2017 at 01:21:52PM +0800, shuw...@redhat.com wrote:
> From: Shu Wang
>
> Kmemleak reports about a thousand false positives for fusion->
> cmd_list[]. Root casue is the cmd_list objects are allocated from
> slab allocator, and stored its pointer in object allocated by page
> alloca
From: Shu Wang
Kmemleak reports about a thousand false positives for fusion->
cmd_list[]. Root casue is the cmd_list objects are allocated from
slab allocator, and stored its pointer in object allocated by page
allocator. The fix will tell kmemleak to track and scan fusion
object.
V2:
Add commen
7 matches
Mail list logo
