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 X-Spam-Level: X-Spam-Status: No, score=-5.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2E030C43331 for ; Sun, 10 Nov 2019 15:57:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0295F2085B for ; Sun, 10 Nov 2019 15:57:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1573401431; bh=7PYw9STwXOGUfy5HvFUTGTdM4guCM6cGoVDiFcC/t1w=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=VeFizSbqsm3+1lO0WHSpgDyiSurImNSLYTPk7t645tdei88gM8dsgv8pvu8sbP4tq oTIMpbQL8umeQ6EQiJhnSs0sVuo76O4oqFaW1nvjBOwRR0GaYEeibft5JykoD0JDLo xg+RfaLpDDSeaV+HhT2MXXXJhZ24gLyXIdC9xRUM= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726832AbfKJP5H (ORCPT ); Sun, 10 Nov 2019 10:57:07 -0500 Received: from mail.kernel.org ([198.145.29.99]:60874 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726902AbfKJP5H (ORCPT ); Sun, 10 Nov 2019 10:57:07 -0500 Received: from localhost (unknown [73.61.17.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 693E42077C; Sun, 10 Nov 2019 15:57:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1573401425; bh=7PYw9STwXOGUfy5HvFUTGTdM4guCM6cGoVDiFcC/t1w=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pFHEu2u1qmOImc7R8TT94KsjtNA9EObF9e3nCftwk5/iZUmZlDFnkFgAl/Isu0h0+ 0YOqeJKehsUJu07xn8VsdNVRf29GxsLqOkqnFU3otFoVZFqX4uidiXjwoxrs2MhM6T mqvEbU1E4wAg+XDXBYDCOC2T2QzvdA+Sd/6uM4gg= Date: Sun, 10 Nov 2019 10:56:55 -0500 From: Sasha Levin To: Ard Biesheuvel Cc: Linux Kernel Mailing List , stable , Jeremy Linton , linux-efi Subject: Re: [PATCH AUTOSEL 4.19 133/191] efi: honour memory reservations passed via a linux specific config table Message-ID: <20191110155655.GO4787@sasha-vm> References: <20191110024013.29782-1-sashal@kernel.org> <20191110024013.29782-133-sashal@kernel.org> <20191110132726.GN4787@sasha-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-efi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org On Sun, Nov 10, 2019 at 02:16:57PM +0000, Ard Biesheuvel wrote: >On Sun, 10 Nov 2019 at 13:27, Sasha Levin wrote: >> >> On Sun, Nov 10, 2019 at 08:33:47AM +0100, Ard Biesheuvel wrote: >> >On Sun, 10 Nov 2019 at 03:44, Sasha Levin wrote: >> >> >> >> From: Ard Biesheuvel >> >> >> >> [ Upstream commit 71e0940d52e107748b270213a01d3b1546657d74 ] >> >> >> >> In order to allow the OS to reserve memory persistently across a >> >> kexec, introduce a Linux-specific UEFI configuration table that >> >> points to the head of a linked list in memory, allowing each kernel >> >> to add list items describing memory regions that the next kernel >> >> should treat as reserved. >> >> >> >> This is useful, e.g., for GICv3 based ARM systems that cannot disable >> >> DMA access to the LPI tables, forcing them to reuse the same memory >> >> region again after a kexec reboot. >> >> >> >> Tested-by: Jeremy Linton >> >> Signed-off-by: Ard Biesheuvel >> >> Signed-off-by: Sasha Levin >> > >> >NAK >> > >> >This doesn't belong in -stable, and I'd be interested in understanding >> >how this got autoselected, and how I can prevent this from happening >> >again in the future. >> >> It was selected because it's part of a fix for a real issue reported by >> users: >> > >For my understanding, are you saying your AI is reading launchpad bug >reports etc? Because it is marked AUTOSEL. Not quite. This review set was me feeding all the patches Ubuntu has on top of stable trees into AUTOSEL, and sending out the output for review. I doesn't look into launchpad bug reports on it's own, but in my experience one can find a bug report for mostly everything AUTOSEL considers to be a bug. >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1806766 >> > >That pages mentions > >""" >2 upstream patch series are required to fix this: > https://