On 11/12/18 at 3:32 AM, Marc Zyngier wrote:
> On Mon, 12 Nov 2018 02:45:48 +,
> Qian Cai wrote:
> >
> >
> >
> > > On Nov 9, 2018, at 9:45 PM, Qian Cai wrote:
> > >
> > >
> > > On 11/8/18 at 1:05 PM, Ard Biesheuvel wrote:
> > >
> > >> Currently, efi_mem_reserve_persistent() may not
On Mon, 12 Nov 2018 02:45:48 +,
Qian Cai wrote:
>
>
>
> > On Nov 9, 2018, at 9:45 PM, Qian Cai wrote:
> >
> >
> > On 11/8/18 at 1:05 PM, Ard Biesheuvel wrote:
> >
> >> Currently, efi_mem_reserve_persistent() may not be called from atomic
> >> context, since both the kmalloc() call and
> On Nov 9, 2018, at 9:45 PM, Qian Cai wrote:
>
>
> On 11/8/18 at 1:05 PM, Ard Biesheuvel wrote:
>
>> Currently, efi_mem_reserve_persistent() may not be called from atomic
>> context, since both the kmalloc() call and the memremap() call may
>> sleep.
>>
>> The kmalloc() call is easy
On 11/8/18 at 1:05 PM, Ard Biesheuvel wrote:
> Currently, efi_mem_reserve_persistent() may not be called from atomic
> context, since both the kmalloc() call and the memremap() call may
> sleep.
>
> The kmalloc() call is easy enough to fix, but the memremap() call
> needs to be moved into an
On Thu, 2018-11-08 at 19:05 +0100, Ard Biesheuvel wrote:
> Currently, efi_mem_reserve_persistent() may not be called from atomic
> context, since both the kmalloc() call and the memremap() call may
> sleep.
>
> The kmalloc() call is easy enough to fix, but the memremap() call
> needs to be moved
Currently, efi_mem_reserve_persistent() may not be called from atomic
context, since both the kmalloc() call and the memremap() call may
sleep.
The kmalloc() call is easy enough to fix, but the memremap() call
needs to be moved into an init hook since we cannot control the
memory allocation