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 6CF92C38145 for ; Thu, 8 Sep 2022 05:17:32 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id AAB3B84062; Thu, 8 Sep 2022 07:17:29 +0200 (CEST) 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="ddUY7y/B"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id DE042845E1; Thu, 8 Sep 2022 07:17:27 +0200 (CEST) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 E43258402F for ; Thu, 8 Sep 2022 07:17:24 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=takahiro.akashi@linaro.org Received: by mail-pf1-x433.google.com with SMTP id y127so16795491pfy.5 for ; Wed, 07 Sep 2022 22:17:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date:from:to:cc :subject:date; bh=4lMIJq3H1X9uANMQ8Et+hp+hKC2JA9VGvr3jFExaNGc=; b=ddUY7y/BxLDvQLJdME4yJGHh2USMYm/XktqgM2eivBdeEzPqArlGbxTIctH/L2ujbc mRTCXxGxoDMEGAKJUVQn7CvP757uOSTnIL6HsmHl2UJS9s/eEmQu6BPpaTtx24Nw2g5y rTIRKnQS4F/64Ph3h/0gCMkaCYAMakT1B7/CRHhTThcu7k9z8iQK1UnprXZKs6jIY9UC Mro81UhToOy/hnzlWcLHvzQFn6XFL/qWgFnWk3PhtOuOgheYiVlOX69pmPqwe0xy8rHw wDkMORbQRAdZJgn2payamJnXP7zMvMyYIgmpvJv9YWGGuOPJtb59hE0lLG0Bf69eEZWx sAOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date; bh=4lMIJq3H1X9uANMQ8Et+hp+hKC2JA9VGvr3jFExaNGc=; b=bYNcfYNjLhz1YlVBqF/E5p+jfj3PuByo3QWyD75mVUHu2NS3W55cuwCVtp8f6Fhn0r Vuhve4KHlPGrQGAXP7XQj1uBKU9Os0lVQ1Xk4KhoBsfQ+rx0LOMxjnm4Q9rbMw2InXVt v9lRYHcOJMnLZdTtAQZwNt1Dz8L/r/3wU/7OvlYqb9iL87PnRsrY3GRY81ECZHyBa6py HLhgFe4HtzNdj/aJZBwrSMem1ALTqbVARViRRKTTvF8Lw9O54roqeWtntT94AEwNbXRe ViDkrtdbzoZ+R7MHFwYQDZa5KQYkm1lLZm6yDRKzJ3WLCsgqLFpzUd2XUO4LZ7rsIaOz lFkQ== X-Gm-Message-State: ACgBeo0PEwofL73vVInewPqL1e+iPlrHq4JOQvbMpw2BYkcxvQTlKV3I OADPVjxVDwejuc1Ro6ftBmMMPw== X-Google-Smtp-Source: AA6agR46Nrei3neqp5VgPgaRPr7tRuhwsQoKxcVqK6wAGWZN3IIaoblnDfTnmY/mc90WbFl437CaHQ== X-Received: by 2002:a05:6a00:248a:b0:538:690e:fdbc with SMTP id c10-20020a056a00248a00b00538690efdbcmr7387344pfv.47.1662614243165; Wed, 07 Sep 2022 22:17:23 -0700 (PDT) Received: from laputa ([2400:4050:c3e1:100:94a6:872b:a3b8:a4ba]) by smtp.gmail.com with ESMTPSA id l10-20020a170902f68a00b00176dc72ad88sm4309022plg.287.2022.09.07.22.17.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Sep 2022 22:17:22 -0700 (PDT) Date: Thu, 8 Sep 2022 14:17:18 +0900 From: AKASHI Takahiro To: Simon Glass Cc: Etienne Carriere , U-Boot Mailing List , Heinrich Schuchardt , Ilias Apalodimas Subject: Re: [PATCH] [RFC] lib: efi_loader: don't delete invalid handles Message-ID: <20220908051718.GA49917@laputa> Mail-Followup-To: AKASHI Takahiro , Simon Glass , Etienne Carriere , U-Boot Mailing List , Heinrich Schuchardt , Ilias Apalodimas References: <20220907082013.66879-1-etienne.carriere@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 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.6 at phobos.denx.de X-Virus-Status: Clean On Wed, Sep 07, 2022 at 03:10:44PM -0600, Simon Glass wrote: > Hi Etienne, > > On Wed, 7 Sept 2022 at 02:20, Etienne Carriere > wrote: > > > > Changes efi_delete_handle() to not free EFI handles that are not related > > to EFI objects. > > > > This change tries to resolved an issue seen since U-Boot v2022.07 > > in which EFI ExitBootService attempts to release some EFI handles twice. > > > > The issue was seen booting a EFI shell that invokes 'connect -r' and > > then boots a Linux kernel. Execution of connect command makes EFI > > subsystem to bind a block device for each root block devices EFI handles. > > However these EFI device handles are already bound to a driver and we > > can have 2 registered devices relating to the same EFI handler. On > > ExitBootService, the loop removing the devices makes these EFI handles > > to be released twice which corrupts memory. > > > > This patch prevents the memory release operation caused by the issue but > > I don't think this patch is the right way to addresse the problem. Any > > help will be much appreciated. > > > > Signed-off-by: Etienne Carriere > > --- > > lib/efi_loader/efi_boottime.c | 8 +++++++- > > 1 file changed, 7 insertions(+), 1 deletion(-) > > +AKASHI Takahiro who has been working on resolving the mismatch > between driver model and the EFI implementation. We should be able to > attach EFI data structures to driver model devices, which may help > with this issue. The only driver which supports DRIVER_BINDING_PROTOCOL, hence connect_controller() interface, in the current UEFI implementation is "EFI block driver" (lib/efi_driver/efi_block_device.c). *Ordinary* block devices, other than UCLASS_EFI_LOADER, are set up without *binding* step. Nevertheless, "connect -r" eventually ends up calling "bind" operation of efi_block_device against those devices. I guess that it is the root cause. efi_uc_supported() should have a stricter check. -Takahiro Akashi > What is the next step, there? > > Regards, > Simon