linux-kernel - Re: [PATCH 3/6] UBI: Fastmap: Notify user in case of an ubi_update

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 07 Dec 2014 15:22:32 +0100
From:	Richard Weinberger <richard@....at>
To:	Tanya Brokhman <tlinder@...eaurora.org>, dedekind1@...il.com
CC:	linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/6] UBI: Fastmap: Notify user in case of an ubi_update_fastmap()
 failure

Am 07.12.2014 um 14:59 schrieb Tanya Brokhman:
> Hi Richard,
> 
> On 11/30/2014 1:35 PM, Richard Weinberger wrote:
>> If ubi_update_fastmap() fails notify the user.
>> This is not a hard error as ubi_update_fastmap() makes sure that upon failure
>> the current on-flash fastmap will no be used upon next UBI attach.
>>
>> Signed-off-by: Richard Weinberger <richard@....at>
>> ---
>>   drivers/mtd/ubi/wl.c | 6 +++++-
>>   1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mtd/ubi/wl.c b/drivers/mtd/ubi/wl.c
>> index 523d8a4..7821342 100644
>> --- a/drivers/mtd/ubi/wl.c
>> +++ b/drivers/mtd/ubi/wl.c
>> @@ -657,7 +657,11 @@ again:
>>        * refill the WL pool synchronous. */
>>       if (pool->used == pool->size || wl_pool->used == wl_pool->size) {
>>           spin_unlock(&ubi->wl_lock);
>> -        ubi_update_fastmap(ubi);
>> +        ret = ubi_update_fastmap(ubi);
>> +        if (ret) {
>> +            ubi_msg(ubi, "Unable to write a new fastmap: %i", ret);
>> +            return -ENOSPC;
> 
> Why do you fail the whole function (ubi_wl_get_peb) if fastmap update failed? Its possible that the fm_pools were refilled correctly, and the actual fastmap_write failed, so there
> is nothing preventing the user to get peb allocated and continue working. You invalidate the fastmap, so if powercut occurs a full scan will be performed. So its possible to
> allocate from fm_pools (although fastmap is not valid on disc) and try writing fastmap again when the pools filled up.
> I'm for the ubi_msg but against "return -ENOSPC;"

Maybe the case you've described is powercut safe, but there can be other unsafe cases.
Let's stay on the safe side and be paranoid, it does not hurt.
If fastmap has proven stable we can start with tricky optimizations.

Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/