From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 00994C433F5 for ; Thu, 9 Dec 2021 07:37:55 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 3942383176; Thu, 9 Dec 2021 08:37:53 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="LW1Wqd65"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 15ACC832FC; Thu, 9 Dec 2021 08:37:51 +0100 (CET) Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 743E18022E for ; Thu, 9 Dec 2021 08:37:47 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=ilias.apalodimas@linaro.org Received: by mail-yb1-xb2d.google.com with SMTP id f9so11608601ybq.10 for ; Wed, 08 Dec 2021 23:37:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9uI2KEQbQY+51oVzNsgcUFkUALlQcfAKLtio/JBzqbM=; b=LW1Wqd65etBBqpDuNNiHHFkuFq6E6Le1G3jSWzII/jGySn6aZiv1RWLKNNSHqbpZzO SoGQEtRKnd40YYUKFBd9p7NEVR+ca10DDGaXKMm7ch8k1dAB3SRQexEEqKobvfjMKSgE ZTw1gh8cQxMhk85aWAtQf3a3tmSEpryUI3Q4dMAK8//pPNP0SsYbYMAseO38lQefDFQ3 3H8IYDcCTrhojsWbKx594W9KfozsADu87C+wj47z89PGWooZFBuCGO1IFzkfWMzdbMgX hPv8EmtzLYPdljH7aYczO9FH7a2PMKx2H0kaeCjKINFC2Ap1qXKTSn9asarISLkFXZm2 4Z4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9uI2KEQbQY+51oVzNsgcUFkUALlQcfAKLtio/JBzqbM=; b=D9C+S8BoweEUdOhNQourUcdn95vkeErckBDgSUY3ilvEiU+FkJTDb9WgXiQvkzEpqV vTaKSK2KQAyKljSEzQpB6OvRj48p9vqmRmVKou90S9kqbuzCrSr38l2gqJkC/Z51zRqR y+OODsnlV4DpMmHEgAxSnDQ0huyDpkpKnu2gQmuITwIR8u3ZL7F0LSOX2COfnDg6ExG3 moPjvV0x5NYolRLVd46AdkXKtI2PIoCZ9u4nLXuxtlKA2G8o0k+gT3hYmRbeONVVp5+p tRNwfL4RhrVBOA7Hb5tJuJ35uD9o86vWajSMfHujgdPsSHUqUM10+Z9KxO/9ZjwPBTzc S5gA== X-Gm-Message-State: AOAM532S/J6Myknkap57YQkrTE0gLIQ5vBrXSTqwSrzzIrVPhOdPj4jH crjoxFq0q7pRz7390pVW7FYe8pZGHyGn3cZXltW4QQ== X-Google-Smtp-Source: ABdhPJxzDHrxZ04v/Fbp0xn8qBM87SJJNvOuFc8oWIghMDmEUjitV5Wp8uVJN5LIew+PVZO6IS0NpY0Jnc26CSy5VkM= X-Received: by 2002:a05:6902:102e:: with SMTP id x14mr4400551ybt.716.1639035465969; Wed, 08 Dec 2021 23:37:45 -0800 (PST) MIME-Version: 1.0 References: <20211125071302.3644-1-sughosh.ganu@linaro.org> <20211125071302.3644-5-sughosh.ganu@linaro.org> In-Reply-To: From: Ilias Apalodimas Date: Thu, 9 Dec 2021 09:37:10 +0200 Message-ID: Subject: Re: [RESEND RFC PATCH 04/10] FWU: Add metadata access functions for GPT partitioned block devices To: Etienne Carriere Cc: Sughosh Ganu , u-boot@lists.denx.de, Patrick Delaunay , Patrice Chotard , Heinrich Schuchardt , Alexander Graf , Simon Glass , Bin Meng , Peng Fan , AKASHI Takahiro , Jose Marinho , Grant Likely , Jason Liu Content-Type: text/plain; charset="UTF-8" X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.38 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean Hi Etienne, [...] > > > > + > > > > + /* And now the replica */ > > > > + ret = gpt_write_metadata_partition(desc, metadata, > > > secondary_mpart); > > > > + if (ret < 0) { > > > > + log_err("Updating secondary metadata partition failed\n"); > > > > + return ret; > > > > + } > > > > > > So shouldn't we do something about this case? The first partition was > > > correctly written and the second failed. Now if the primary GPT somehow > > > gets corrupted the device is now unusable. > > The replica is not there to overcome bitflips of the storage media. > It's here to allow updates while reliable info a still available in > the counter part. Sure but with this piece of code this assumption is broken. At the point the secondary partition fails to write, you loose that reliability. When the next update happens you are left with one valid and one invalid partition of metadata. > The scheme could be to rely on only 1 instance of the fwu-metadata > (sorry Simon) image is valid. > A first load: load 1st instance, crap the second. > At update: find the crapped one: write it with new data. Upon success > crapped the alternate one. > This is a suggestion. There are many ways to handle that. We could change to something like that, however this is not what's currently happening. gpt_check_metadata_validity() is trying to check and make sure both of the partitions are sane. If they aren't it tries to recover those looking at a sane partition. So the question for really is, should we do something *here* or rely on the fact that the next update will try to fix the broken metadata. Cheers /Ilias