From patchwork Sat May 23 08:58:45 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Artem Bityutskiy X-Patchwork-Id: 27561 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 bilbo.ozlabs.org (Postfix) with ESMTPS id BE47AB6F34 for ; Sat, 23 May 2009 19:03:39 +1000 (EST) Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.69 #1 (Red Hat Linux)) id 1M7n4I-0001RV-OE; Sat, 23 May 2009 08:59:03 +0000 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by bombadil.infradead.org with esmtps (Exim 4.69 #1 (Red Hat Linux)) id 1M7n48-0001Pw-Jt for linux-mtd@lists.infradead.org; Sat, 23 May 2009 08:58:59 +0000 Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n4N8wfjb014199; Sat, 23 May 2009 11:58:43 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 23 May 2009 11:58:45 +0300 Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sat, 23 May 2009 11:58:45 +0300 Received: from [172.21.42.232] (esdhcp042232.research.nokia.com [172.21.42.232]) by mgw-sa02.ext.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n4N8wj7b026995; Sat, 23 May 2009 11:58:45 +0300 Subject: Re: a suspected data race in /driver/mtd/ubi/build.c From: Artem Bityutskiy To: =?UTF-8?Q?=ED=99=8D=EC=8B=A0?= shin hong In-Reply-To: <2014bcab0905190434r687de23ued2af901636cd16c@mail.gmail.com> References: <2014bcab0905190434r687de23ued2af901636cd16c@mail.gmail.com> Date: Sat, 23 May 2009 11:58:45 +0300 Message-Id: <1243069125.21646.21.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) X-OriginalArrivalTime: 23 May 2009 08:58:45.0568 (UTC) FILETIME=[ADD9FC00:01C9DB84] X-Nokia-AV: Clean X-Spam-Score: -4.0 (----) X-Spam-Report: SpamAssassin version 3.2.5 on bombadil.infradead.org summary: Content analysis details: (-4.0 points) pts rule name description ---- ---------------------- -------------------------------------------------- -4.0 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium trust [192.100.122.233 listed in list.dnswl.org] Cc: linux-mtd@lists.infradead.org X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: dedekind@infradead.org 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 Tue, 2009-05-19 at 20:34 +0900, 홍신 shin hong wrote: > Hi. I am reporting a susptected data race bug at > ubi_attach_mtd_dev() in /driver/mtd/ubi/build.c . > > This function creates a kernel thread by calling > kthread_create(ubi_thread, ubi .. ). and then > it assigns ubi->thread_enabled = 1. > > However, ubi_thread() also reads ubi->thread_enabled. > This may cause data race since the execution results > would be differ depending on the scheduling. > > I think, ubi_attach_mtd_dev() should be modified to protect > the writing aceess to ubi->thread_enabled > by spin_lock(&ubi->wl_lock). > > But I do not have much background on the code. > So please check this code and let me know your opinions. Agreed, thanks for the report. I'm going to push the following patch (sorry I wrote your name without the hieroglyph characters because my vim refused them). From: Artem Bityutskiy Subject: [PATCH] UBI: fix race condition This patch fixes a minor problem where we may fail to wake upe the UBI background thread. This is not fatal at all, it may just result at sligtly worse performace for a short period of time, just because the thread will be woken up when real I/O on the UBI starts. Anywey, the issue is the race condition between 'ubi_attach_mtd_dev()' and 'ubi_thread()'. If we do not serialize them, the 'wake_up_process()' call may be done before 'ubi_thread()' went seep, but after it checked 'ubi->thread_enabled'. This issue was spotted by Shin Hong Signed-off-by: Artem Bityutskiy --- drivers/mtd/ubi/build.c | 8 +++++++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c index 4048db8..c2c7827 100644 --- a/drivers/mtd/ubi/build.c +++ b/drivers/mtd/ubi/build.c @@ -380,7 +380,7 @@ static void free_user_volumes(struct ubi_device *ubi) * @ubi: UBI device description object * * This function returns zero in case of success and a negative error code in - * case of failure. Note, this function destroys all volumes if it failes. + * case of failure. Note, this function destroys all volumes if it fails. */ static int uif_init(struct ubi_device *ubi) { @@ -872,9 +872,15 @@ int ubi_attach_mtd_dev(struct mtd_info *mtd, int ubi_num, int vid_hdr_offset) ubi->beb_rsvd_pebs); ubi_msg("max/mean erase counter: %d/%d", ubi->max_ec, ubi->mean_ec); + /* + * The below lock makes sure we do not race with 'ubi_thread()' which + * checks @ubi->thread_enabled. Otherwise we may fail to wake it up. + */ + spin_lock(&ubi->wl_lock); if (!DBG_DISABLE_BGT) ubi->thread_enabled = 1; wake_up_process(ubi->bgt_thread); + spin_unlock(&ubi->wl_lock); ubi_devices[ubi_num] = ubi; return ubi_num;