From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Schocher Date: Mon, 25 Apr 2016 07:46:37 +0200 Subject: [U-Boot] [PATCH] mtd, ubi: set free_count to zero before walking through erase list In-Reply-To: <20160422142141.0e440caa@bbrezillon> References: <1454410475-29929-1-git-send-email-hs@denx.de> <20160421105846.696b0eff@bbrezillon> <5718A6DE.6040109@denx.de> <20160421122533.7367cb7c@bbrezillon> <5718B012.8030006@denx.de> <20160421141452.4d9257d3@bbrezillon> <5719F01A.7090400@nod.at> <5719FAE6.2010603@denx.de> <571A0175.2070807@nod.at> <571A109C.6090206@denx.de> <20160422142141.0e440caa@bbrezillon> Message-ID: <571DAF3D.3000002@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Boris, Am 22.04.2016 um 14:21 schrieb Boris Brezillon: > On Fri, 22 Apr 2016 13:53:00 +0200 > Heiko Schocher wrote: > >> >>> An alternative approach would be not executing work >>> directly while scheduling it but in produce_free_peb(). >>> UBI is designed to work with the worker being disabled. >>> All UBI work will then happen synchronous and should also work >>> in u-boot. >> >> Sounds good! > > Not so good actually. I tried that, and ended up with tasks stalled in > the work queue because the implementation was never "scheduling" the > do_work() loop. > > Let's keep it simple, in uboot everything is synchronous, and you can't > be preempted by another task, so it's safe to assume that "scheduling a > work" == "executing it right away". IMHO, the kernel should also assume > that "scheduling a work" might involve "the work may have been done > before the ubi_schedule_work() function returns": when you schedule a > work to be done and wake up the thread responsible for dequeuing UBI > works, the scheduler can decide to schedule this thread right away, > which means this work can be done before the caller gets back to the > instruction just after ubi_schedule_work(). > > Of course, this has to be nuanced for the "attach procedure", because at > this time the UBI thread is not launched yet. But even in this > specific case, I think it's safer to assume that, maybe one day, the UBI > thread might be running when ubi_wl_init() is called, which is why I > suggested to also apply this patch to Linux. Ok, thanks for this explanation! I posted this patch also on linux-mtd, see: https://patchwork.ozlabs.org/patch/613492/ >>>>> In the long run I suggest removing the whole Linux UBI implementation >>>>> from u-boot and add a small (read only!) implementation which can >>>>> also read UBIFS. Reading UBIFS is not a big deal. Also journal reply >>>>> can be done in-memory. >>>> >>>> Hmm.. I think read only is not for all boards an option, as we also >>>> create UBI Volumes and/or write to them in U-Boot ... >>> >>> Depends. >>> IMHO a bootloader has exactly one job, loading a kernel >>> and booting it. And not being a poor man's general purpose operating >>> system where you can also do management stuff like managing UBI volumes. ;-) >> >> Heh... > > That's another topic ;). Oh, yes... bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany