From patchwork Sun Jan 17 10:43:12 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Artem Bityutskiy X-Patchwork-Id: 43021 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 52431B7CE8 for ; Sun, 17 Jan 2010 21:45:08 +1100 (EST) Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.69 #1 (Red Hat Linux)) id 1NWSbJ-0007ua-UO; Sun, 17 Jan 2010 10:43:21 +0000 Received: from mail-fx0-f211.google.com ([209.85.220.211]) by bombadil.infradead.org with esmtp (Exim 4.69 #1 (Red Hat Linux)) id 1NWSbD-0007tb-2H for linux-mtd@lists.infradead.org; Sun, 17 Jan 2010 10:43:19 +0000 Received: by fxm3 with SMTP id 3so1434546fxm.4 for ; Sun, 17 Jan 2010 02:43:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:reply-to:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=A7RphaWZsvTqWPn1POGkafEI4a7Y/hIquUFH1T6Q2/A=; b=XLxsvXf2Hv9vqNaPcXg6TlGaSU8vG4DBMnwPEwMu/jY/m45s3bKobmCeytA7N0ezXp k+rnChF1bnHcnN7eE0FT4GPMrVz1I2/CugMqhiR8jjmXOFFAndKI7YTox5VDXY7lgg2h yEVHTSnmcXn5ARx88s3cETy4LgkeFIsL2HONk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:reply-to:to:cc:in-reply-to:references:content-type :date:message-id:mime-version:x-mailer:content-transfer-encoding; b=r/2lfUDQL+iuRBVtmh0DD/TCxRWsiuQ9o2xnf96vQ15QE9QO2d/zo0geIj6BZw0/rC iP3pCW5N72MEj9nsqJODasKNPTgynhTFl5BTY1SoMgGBuJ7wIDI0Dk+xuDVHcEO9J6S6 qIaVY3OFS5cfB8JHAz7ehZhrehDhENfGHTeQI= Received: by 10.223.76.69 with SMTP id b5mr5734051fak.20.1263724994007; Sun, 17 Jan 2010 02:43:14 -0800 (PST) Received: from ?192.168.255.16? (a91-152-69-107.elisa-laajakaista.fi [91.152.69.107]) by mx.google.com with ESMTPS id 15sm1617308fxm.14.2010.01.17.02.43.12 (version=SSLv3 cipher=RC4-MD5); Sun, 17 Jan 2010 02:43:13 -0800 (PST) Subject: Re: Memory leak on UBI volume truncating From: Artem Bityutskiy To: Marek Skuczynski In-Reply-To: <1263724633.8276.135.camel@localhost.localdomain> References: <1263724633.8276.135.camel@localhost.localdomain> Date: Sun, 17 Jan 2010 12:43:12 +0200 Message-Id: <1263724992.8276.140.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 (2.26.3-1.fc11) X-CRM114-Version: 20090807-BlameThorstenAndJenny ( TRE 0.7.6 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20100117_054315_246661_BA70F378 X-CRM114-Status: GOOD ( 23.30 ) X-Spam-Score: 0.0 (/) X-Spam-Report: SpamAssassin version 3.2.5 on bombadil.infradead.org summary: Content analysis details: (0.0 points) pts rule name description ---- ---------------------- -------------------------------------------------- _SUMMARY_ Cc: linux-mtd@lists.infradead.org X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dedekind1@gmail.com List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-mtd-bounces@lists.infradead.org Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org On Sun, 2010-01-17 at 12:37 +0200, Artem Bityutskiy wrote: > Hi, > > On Wed, 2010-01-13 at 15:28 +0100, Marek Skuczynski wrote: > > Hello, > > I have prepare a simple volume update stress test (see test code below). > > This test has been run for kernel 2.6.23 with some updates from 2.6.28, > > and always after a few minutes the OOM killer was launched. > > > > What i found it that each an UBI volume truncate operation with > > ubiupdatevol tool > > causes memory leak. I think this happens because: > > > > - ubi_start_update() param "bytes" is equal 0 > > > > - vol->updating flag is re-set to 0 > > > > - vol->upd_buf is allocated regardless of vol->updating flag, > > but not released on device close by vol_cdev_release() > > > > I never run the test on a newer kernel version, so I cannot confirm > > that this problem still exists. > > > > Please confirm, whether my findings are correct or not, thanks. > > thanks for this finding. Looks like your analysis is right. Does this > simple patch help? Actually this even simpler patch should fix the issue. Could you please test it and let me know if it helps. diff --git a/drivers/mtd/ubi/upd.c b/drivers/mtd/ubi/upd.c index c1d7b88..425bf5a 100644 --- a/drivers/mtd/ubi/upd.c +++ b/drivers/mtd/ubi/upd.c @@ -155,6 +155,7 @@ int ubi_start_update(struct ubi_device *ubi, struct ubi_volume *vol, if (err) return err; vol->updating = 0; + return 0; } vol->upd_buf = vmalloc(ubi->leb_size);