[U-Boot] [PATCH] mtd, ubi: set free_count to zero before walking through erase list

[Richard Weinberger <richard@nod.at>]

Am 25.04.2016 um 07:46 schrieb Heiko Schocher:
> Hello Boris,
> 
> Am 22.04.2016 um 14:21 schrieb Boris Brezillon:
>> On Fri, 22 Apr 2016 13:53:00 +0200
>> Heiko Schocher <hs@denx.de> 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/

Let's hope that attaching is the only place. :-)
Heiko, it would be cool if you could double check.

Thanks,
//richard