From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752825AbcFFONj (ORCPT ); Mon, 6 Jun 2016 10:13:39 -0400 Received: from verein.lst.de ([213.95.11.211]:40155 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752759AbcFFONh (ORCPT ); Mon, 6 Jun 2016 10:13:37 -0400 Date: Mon, 6 Jun 2016 16:13:34 +0200 From: Christoph Hellwig To: Catalin Marinas Cc: Christoph Hellwig , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, Jens Axboe , Larry.Finger@lwfinger.net, bart.vanassche@sandisk.com, drysdale@google.com Subject: Re: kmemleak report after 9082e87bfbf8 ("block: remove struct bio_batch") Message-ID: <20160606141334.GA6579@lst.de> References: <20160606112620.GA29910@e104818-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160606112620.GA29910@e104818-lin.cambridge.arm.com> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Catalin, I've got a few reports of this over the weekend, but it still doesn't make much sense to me. Could it be that kmemleak can't deal with the bio_batch logic? I've tried to look at the various bio and biovec number entries in /proc/slabinfo, and while they keep changing a bit during the system runtime there doesn't seem to be a persistent increase even after lots of mkfs calls. Can all of you who have reported the issue take a look at their slabinfo files and check if you can confirm that observation?