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 B0D49C17442 for ; Sun, 10 Nov 2019 15:57:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 85E092077C for ; Sun, 10 Nov 2019 15:57:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1573401428; bh=7PYw9STwXOGUfy5HvFUTGTdM4guCM6cGoVDiFcC/t1w=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=KtGAaKQpqWe0+yd4O9btb5fMcpKhKsGg+zw7bFAXE3+3S1fgPidABaKWtsHMZYG7Y Fux8+PX4eIddWvmugRwvHOFCAhLG0xjFUvE1ksPSUZrIBJFw2fIKAllszLiR7KVoIX tClE1KLllX6PX5l/K3Saayl4HwZ9mghlNyY22ST4= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727002AbfKJP5H (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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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://