Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1894519imu; Sat, 12 Jan 2019 10:02:08 -0800 (PST) X-Google-Smtp-Source: ALg8bN7Zswh+vaiAAYOTUDP54jBqTRYcZjfiA5IdSYtgAch90nJkRpB1AdXmpBA1Ymq7bJ7S5eVJ X-Received: by 2002:a62:6503:: with SMTP id z3mr18752658pfb.169.1547316128026; Sat, 12 Jan 2019 10:02:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547316127; cv=none; d=google.com; s=arc-20160816; b=iznk/UN+9wZpbiV3J9HfShW4E1uYye+JroLy1m4lRSlEkkaxbQdNy/9oaseaC4l6wK W3DarJOW0UjhC65jcyOTXo107O6a/JVrQbW7aT5rnjQLNuFgE8hLfv9cmqp6WZ80r466 EbwKs+woJBT6j0HFxzgGl7WNJW4FRy4djnYDknS3R2io9uQBD7MDd0IC00MyPNm+a6A5 kNUDc3zLneOZpMaxKqRznBdYwx78nsnEmVZebDx2rdFx5uWMJQS+Z2V3px3CYxsKBWuG RsQUgozvMU88+HzphWFSAihWyQP98FkFAFBQMZcIPR1+dupJPJaat3mJnY/tt1cTdZOB v8QA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version; bh=a7T8blUvkMpBCxg09FUirgEQpnp9prXTKr0oC8tX4bY=; b=A0rswOXI+B69QAmX07nQJmyDmWyA5raujWubbB4sEscYEmJBWUvFUb1VkdX75hfj2P mVYkF73XbCca1j8tHlgcwAmkqq8DokokA+d4KiEx0kDki5+BeMVGPWKI1wdWPz144jQ0 1wiAQHjPSrjS8tPzDVrQq429jvIRE6w7+n/pvw4rhADiwXeFZRCm4Ow+E5yyt9McSFrF PIuNivr2PAgWEnO1Iph5d4bn0S3ZqJ8n2T9lTT4bBO7R3T9ulIcrM50nk+jpVhIPg+bd bGMBAECAPxMkKgWKIq4G5U4YSKhD8dTvLn8zbtPInyN7X+9pNxLLEOg0hdb/5HPbVzL/ aQSA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n19si6480108pgd.271.2019.01.12.10.01.52; Sat, 12 Jan 2019 10:02:07 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725861AbfALRTF (ORCPT + 99 others); Sat, 12 Jan 2019 12:19:05 -0500 Received: from mx2.suse.de ([195.135.220.15]:46900 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725843AbfALRTF (ORCPT ); Sat, 12 Jan 2019 12:19:05 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 32802AD96; Sat, 12 Jan 2019 17:19:04 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 12 Jan 2019 18:19:03 +0100 From: Roman Penyaev To: Andrey Ryabinin Cc: Andrew Morton , Michal Hocko , Joe Perches , "Luis R. Rodriguez" , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/3] mm/vmalloc: do not call kmemleak_free() on not yet accounted memory In-Reply-To: References: <20190103145954.16942-1-rpenyaev@suse.de> <20190103145954.16942-3-rpenyaev@suse.de> Message-ID: <6557efeadcb4fdedbd9c36947e644e2f@suse.de> X-Sender: rpenyaev@suse.de User-Agent: Roundcube Webmail Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019-01-11 20:26, Andrey Ryabinin wrote: > On 1/3/19 5:59 PM, Roman Penyaev wrote: >> __vmalloc_area_node() calls vfree() on error path, which in turn calls >> kmemleak_free(), but area is not yet accounted by kmemleak_vmalloc(). >> >> Signed-off-by: Roman Penyaev >> Cc: Andrew Morton >> Cc: Michal Hocko >> Cc: Andrey Ryabinin >> Cc: Joe Perches >> Cc: "Luis R. Rodriguez" >> Cc: linux-mm@kvack.org >> Cc: linux-kernel@vger.kernel.org >> --- >> mm/vmalloc.c | 16 +++++++++++----- >> 1 file changed, 11 insertions(+), 5 deletions(-) >> >> diff --git a/mm/vmalloc.c b/mm/vmalloc.c >> index 2cd24186ba84..dc6a62bca503 100644 >> --- a/mm/vmalloc.c >> +++ b/mm/vmalloc.c >> @@ -1565,6 +1565,14 @@ void vfree_atomic(const void *addr) >> __vfree_deferred(addr); >> } >> >> +static void __vfree(const void *addr) >> +{ >> + if (unlikely(in_interrupt())) >> + __vfree_deferred(addr); >> + else >> + __vunmap(addr, 1); >> +} >> + >> /** >> * vfree - release memory allocated by vmalloc() >> * @addr: memory base address >> @@ -1591,10 +1599,8 @@ void vfree(const void *addr) >> >> if (!addr) >> return; >> - if (unlikely(in_interrupt())) >> - __vfree_deferred(addr); >> - else >> - __vunmap(addr, 1); >> + >> + __vfree(addr); >> } >> EXPORT_SYMBOL(vfree); >> >> @@ -1709,7 +1715,7 @@ static void *__vmalloc_area_node(struct >> vm_struct *area, gfp_t gfp_mask, >> warn_alloc(gfp_mask, NULL, >> "vmalloc: allocation failure, allocated %ld of %ld bytes", >> (area->nr_pages*PAGE_SIZE), area->size); >> - vfree(area->addr); >> + __vfree(area->addr); > > This can't be an interrupt context for a several reasons. One of them > is BUG_ON(in_interrupt()) in __get_vm_area_node() > which is called right before __vmalloc_are_node(). > > So you can just do __vunmap(area->addr, 1); instead of __vfree(). Thanks, I missed that BUG_ON and could not prove, that we can call only from a task context, thus decided not to make it strict. Of course simple __vunmap() is much better. The other reason is that we call a spin_lock without disabling the interrupts. Now I see. Andrew, may I resend just an updated version of this patch? -- Roman