From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752567AbcD3UBa (ORCPT ); Sat, 30 Apr 2016 16:01:30 -0400 Received: from mail-pa0-f45.google.com ([209.85.220.45]:36753 "EHLO mail-pa0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752022AbcD3UB2 (ORCPT ); Sat, 30 Apr 2016 16:01:28 -0400 Date: Sat, 30 Apr 2016 21:01:24 +0100 From: Matt Fleming To: "Compostella, Jeremy" Cc: Ingo Molnar , stefan.stanacar@intel.com, peterz@infradead.org, linux-kernel@vger.kernel.org, tglx@linutronix.de, hpa@zytor.com, bp@alien8.de, ard.biesheuvel@linaro.org, linux-tip-commits@vger.kernel.org Subject: Re: [tip:efi/core] efibc: Add EFI Bootloader Control module Message-ID: <20160430200124.GJ2839@codeblueprint.co.uk> References: <1461614832-17633-26-git-send-email-matt@codeblueprint.co.uk> <20160429095356.GA29957@gmail.com> <20160429103011.GE2839@codeblueprint.co.uk> <87lh3wejfi.fsf@jcompost-MOBL1.tl.intel.com> <20160429121635.GF2839@codeblueprint.co.uk> <87h9eked24.fsf@jcompost-MOBL1.tl.intel.com> <20160429194615.GA22691@gmail.com> <874majebs3.fsf@jcompost-MOBL1.tl.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <874majebs3.fsf@jcompost-MOBL1.tl.intel.com> User-Agent: Mutt/1.5.24+41 (02bc14ed1569) (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 30 Apr, at 10:33:32AM, Jeremy Compostella wrote: > Ingo Molnar writes: > > > > Hm, can reboot notifiers do non-atomic allocations? > The reboot notifier chain is a blocking notifier chain. AFAIK, it > allows non-atomic allocation, right ? I would assume so, yes. > > Why is efivar_entry so huge? > efivar_entry structure include two "big" arrays of 1024 bytes each for > the EFI variable name and data. Yeah. This is partially historical in that the EFI variable code has always had these arrays. But it's also that if you're dealing with EFI variables you always want someplace to cache the data and name, so no one has ever proposed to split out the data/name from struct efivar_entry. We've never put them on the stack before either ;)