From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Fleming Subject: Re: [PATCH 2/4] efi: efivars: don't rely on blocking operations in non-blocking set_var() Date: Fri, 27 Nov 2015 21:18:36 +0000 Message-ID: <20151127211836.GB13918@codeblueprint.co.uk> References: <1447940191-30705-1-git-send-email-ard.biesheuvel@linaro.org> <1447940191-30705-3-git-send-email-ard.biesheuvel@linaro.org> <20151126095441.GA2765@codeblueprint.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-efi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Ard Biesheuvel Cc: "linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Leif Lindholm , Mark Rutland , Matthew Garrett , Tony Luck List-Id: linux-efi@vger.kernel.org On Thu, 26 Nov, at 01:06:27PM, Ard Biesheuvel wrote: > > How would this be affected by things like suspend/resume, hibernation > or variable accesses made in SMM context (i.e., which the kernel knows > nothing about) > If we need to take all of that into account as well, we're probably > better off adding a nonblocking query_variable_info() call after all, > and wiring it up to efi_query_variable_store(), i.e., make it take a > 'bool nonblocking' argument and choose between the two versions of > each of the hooks it uses. I *think* that'd be OK. The thing I wanted to avoid was a proliferation of nonblocking versions of the standard EFI calls, but limiting it to adding query_variable_info() doesn't seem too bad. Let me think about it over the weekend.