Subject: Re: [PATCH v2] module: check if memory leak by module.
To: Pavel Machek <pavel@ucw.cz>
References: <CGME20170329060315epcas5p1c6f7ce3aca1b2770c5e1d9aaeb1a27e1@epcas5p1.samsung.com>
 <1490767322-9914-1-git-send-email-maninder1.s@samsung.com>
 <460c5798-1f4d-6fd0-cf32-349fbd605862@virtuozzo.com>
 <20170330133712.GA23946@amd>
CC: Maninder Singh <maninder1.s@samsung.com>, <jeyu@redhat.com>,
        <rusty@rustcorp.com.au>, <akpm@linux-foundation.org>,
        <chris@chris-wilson.co.uk>, <joonas.lahtinen@linux.intel.com>,
        <mhocko@suse.com>, <keescook@chromium.org>, <jinb.park7@gmail.com>,
        <anisse@astier.eu>, <rafael.j.wysocki@intel.com>, <zijun_hu@htc.com>,
        <mingo@kernel.org>, <mawilcox@microsoft.com>, <thgarnie@google.com>,
        <joelaf@google.com>, <kirill.shutemov@linux.intel.com>,
        <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
        <pankaj.m@samsung.com>, <ajeet.y@samsung.com>,
        <hakbong5.lee@samsung.com>, <a.sahrawat@samsung.com>,
        <lalit.mohan@samsung.com>, <cpgs@samsung.com>,
        Vaneet Narang <v.narang@samsung.com>
From: Andrey Ryabinin <aryabinin@virtuozzo.com>
Message-ID: <06383e49-148e-e31f-e66e-e50db7df470b@virtuozzo.com>
Date: Thu, 30 Mar 2017 17:31:45 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <20170330133712.GA23946@amd>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Mar 2017 14:30:22.1707 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0801MB2055
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 888
Lines: 29


On 03/30/2017 04:37 PM, Pavel Machek wrote:
>  
>>  3) This might produce false positives. E.g. module may defer vfree() in workqueue, so the 
>>      actual vfree() call happens after module unloaded.
> 
> Umm. Really?
> 

I should have been more specific. I meant vfree() called by module from the interrupt context.
In that case the actual __vunmap() will be deferred via schedule_work() thus it might happen
after the module unloaded.
See 32fcfd40715e ("make vfree() safe to call from interrupt contexts")

> I agree that module may alloc memory and pass it to someone else. Ok
> so far.
> 

Right. In the case with vfree() from interrupt we actually pass the memory to
the core code to free it later. 

> But if module code executes after module is unloaded -- that is use
> after free -- right?

Sure, module code can't execute after module unloaded, it doesn't exist anymore.