Received: by 10.192.165.148 with SMTP id m20csp1759961imm; Thu, 3 May 2018 05:06:54 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpMTsfrrWWLBauQqG91eFwnx+WqrB2EGGk/qcxQArIkoOe5xWA3KUmxdCA/sxbFYcgSka7h X-Received: by 2002:a63:8f16:: with SMTP id n22-v6mr18458780pgd.394.1525349214096; Thu, 03 May 2018 05:06:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525349214; cv=none; d=google.com; s=arc-20160816; b=Fhn0MW5QMVNhdXWxeDpDaGBKfLXY0aWnjfSmIF83ADh/HqefNz6DVAe3V1jUcMDEH5 iwAjGN4aXZIK1PO7CqhyVd9KddHpgKCebUgN1I63jOgRldJ7hPQ4l99B+EUTvWUPXbzb ZGzo2uyS1x20ExFtv8iOiAuc5elAPkD6LCA9hY/r61vp9EW4jC2iAFqw8jwt9BNybJSX W3F9oAs2fqQte+ut65EuqIkA8yvIVbZYLW7o7t66PsGcmINuEE7rH5BEBO4ZG9UhLyG/ 98zraTIzZGTqMJcIXiseB4v+Nb7ecCPUG8eLklJjmXvuEiqZ0gO/hB8dKQy76MzM1ODF Vcbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=3kSNtG0baNUS99v4hdmOMkD712Fv1m6hJs8R9UtuT9c=; b=FfeLF5anHZ0yMQ7ubhSjM/t5HnbpwDgFf6QNd2nUTNdBlIObT/cVQj3lmW2P1MjH8I gVN+JRpkrf8k6kVs6RpG+7e6EACCSpLIj5xOhAaHnVyDQZtxzQWzsrDJIesas9zY6dZr wZ4Zd/Nzh0nbWQV2fW7roy3T7O9wodJImlo9X760s9noo0/oqQr+lTZBcexcusrVN3Me 8wPD5vgj89a4Mr1rPywbYlwrO95372CrSOP9+5miTC+J3FkT2hwGo/zPf0N4HSCSGQrS EOMAEyXDeXFFYIwERF8m/6NrPHoei2u63hud9WOEpOY4vdeAO6whILAoS/P6uZjB8yHB us7w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=KaagU4H+; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f59-v6si13803213plf.38.2018.05.03.05.06.38; Thu, 03 May 2018 05:06:54 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=KaagU4H+; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751355AbeECMF4 (ORCPT + 99 others); Thu, 3 May 2018 08:05:56 -0400 Received: from mail-it0-f66.google.com ([209.85.214.66]:52706 "EHLO mail-it0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750999AbeECMFw (ORCPT ); Thu, 3 May 2018 08:05:52 -0400 Received: by mail-it0-f66.google.com with SMTP id i136-v6so12569412ita.2 for ; Thu, 03 May 2018 05:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3kSNtG0baNUS99v4hdmOMkD712Fv1m6hJs8R9UtuT9c=; b=KaagU4H+nPt9cw+HpEPo0ocSxuzYovorjJ72+C8ppaIoJ05Xtr3PWShKG642xU9Ubn pJ9MqN3XJK6NsprUsXzEmcVyT4Axbnbjq0APLvZehkof1Hl07/6BJnfpQNlFTCgsU/su SP8gAhf/n7GMa5ht1i8njc579mgswN6z1ttzk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3kSNtG0baNUS99v4hdmOMkD712Fv1m6hJs8R9UtuT9c=; b=OYf45gtq7N+mnFtlU9u4g6I6uVR3bYrd7aArJw1nSKBV51DPD73gacCVLxUkTDkfMD reb606BiAvdfp3ftTmH+QQRA+1FybmZUvKt8uu3ceM3ZDh6oXczyHmKuLq/gv0uWGgRT MLML0+hLKzJWmr4XQ8lmE1m3gi71b3+qNrTf4jQsUSmmdARJuwqVSWVlOX57DPZDKTce QSjzgpy4qzB7bapiESf0cyvZ28AsweKxbbImYw0kMpotF9lGM8I6rN4V+wv0OLIQvSOH MChysf6vrWXj4meuLJ8pi2SN8cB73ko1iF80eMq97sSmyRw5HzTy896OxlBdLikvglQ1 pSeg== X-Gm-Message-State: ALQs6tB8/R0XiOemkYKnTKXTuMyDim89t/3ZnQZD06ZG5BlUkeu1D2a6 BvZHc3lgowMRFhGbD73Td5e5yz4dxyG5+pnHLcfZBQ== X-Received: by 2002:a24:534e:: with SMTP id n75-v6mr13449299itb.138.1525349152015; Thu, 03 May 2018 05:05:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.187.134 with HTTP; Thu, 3 May 2018 05:05:51 -0700 (PDT) In-Reply-To: <20180502061724.25833-1-jlee@suse.com> References: <20180502061724.25833-1-jlee@suse.com> From: Ard Biesheuvel Date: Thu, 3 May 2018 14:05:51 +0200 Message-ID: Subject: Re: [PATCH] efi: Fix the size not consistent issue when unmapping memory map To: "Lee, Chun-Yi" Cc: linux-efi@vger.kernel.org, Linux Kernel Mailing List , "Lee, Chun-Yi" , Takashi Iwai , Vivek Goyal , Ingo Molnar Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2 May 2018 at 08:17, Lee, Chun-Yi wrote: > When using kdump, SOMETIMES the "size not consistent" warning message > shows up when the crash kernel boots with early_ioremap_debug parameter: > > WARNING: CPU: 0 PID: 0 at ../mm/early_ioremap.c:182 early_iounmap+0x4f/0x12c() > early_iounmap(ffffffffff200180, 00000118) [0] size not consistent 00000120 > > The root cause is that the unmapping size of memory map doesn't > match with the original size when mapping: > > in __efi_memmap_init() > map.map = early_memremap(phys_map, data->size); > > in efi_memmap_unmap() > size = efi.memmap.desc_size * efi.memmap.nr_map; > early_memunmap(efi.memmap.map, size); > > But the efi.memmap.nr_map is from __efi_memmap_init(). The remainder > of size was discarded when calculating the nr_map: > map.nr_map = data->size / data->desc_size; > > When the original size of memory map region does not equal to the > result of multiplication. The "size not consistent" warning > will be triggered. > > This issue sometimes was hit by kdump because kexec set the efi map > size to align with 16 when loading crash kernel image: > > in bzImage64_load() > efi_map_sz = efi_get_runtime_map_size(); > efi_map_sz = ALIGN(efi_map_sz, 16); > > Dave Young's a841aa83d patch fixed kexec issue. On UEFI side, this > patch changes the logic in the unmapping function. Using the end > address of map to calcuate original size. > Why do we still need this patch? I.e., in which circumstances will efi_memory_map_data::size assume a value that is rounded up or otherwise incorrect? > Thank Randy Wright for his report and testing. And also thank > Takashi Iwai for his help to trace issue. > > Cc: Ard Biesheuvel > Cc: Takashi Iwai > Cc: Vivek Goyal > Cc: Ingo Molnar > Tested-by: Randy Wright > Signed-off-by: "Lee, Chun-Yi" > --- > drivers/firmware/efi/memmap.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/firmware/efi/memmap.c b/drivers/firmware/efi/memmap.c > index 5fc7052..1f592d8 100644 > --- a/drivers/firmware/efi/memmap.c > +++ b/drivers/firmware/efi/memmap.c > @@ -121,7 +121,7 @@ void __init efi_memmap_unmap(void) > if (!efi.memmap.late) { > unsigned long size; > > - size = efi.memmap.desc_size * efi.memmap.nr_map; > + size = efi.memmap.map_end - efi.memmap.map; > early_memunmap(efi.memmap.map, size); > } else { > memunmap(efi.memmap.map); > -- > 2.10.2 >