On 13/01/2025 12:00, Usama Arif wrote:
>
>
> On 13/01/2025 11:27, Usama Arif wrote:
>>
>>
>> On 13/01/2025 02:33, Dave Young wrote:
>>> On Fri, 10 Jan 2025 at 18:54, Usama Arif wrote:
On 10/01/2025 07:21, Ard Biesheuvel wrote:
> On Thu, 9 Jan 2025 at 17:36, Usama Arif
On 20/01/2025 10:32, Ard Biesheuvel wrote:
> On Mon, 20 Jan 2025 at 11:27, Usama Arif wrote:
>>
>>
> ...
>> Hi Ard,
>>
>> Just wanted to check how should we proceed forward? Should we try and fix
>> the warning
>> and corruption during kexec as done in this series or not initialize memory
>>
On 20/01/2025 11:29, Ard Biesheuvel wrote:
> On Mon, 20 Jan 2025 at 11:50, Usama Arif wrote:
>>
>>
>>
>> On 20/01/2025 10:32, Ard Biesheuvel wrote:
>>> On Mon, 20 Jan 2025 at 11:27, Usama Arif wrote:
>>> ...
Hi Ard,
Just wanted to check how should we proceed forward? S
On 22/01/2025 05:36, Dave Young wrote:
> Hi,
> On Mon, 20 Jan 2025 at 19:48, Usama Arif wrote:
>>
>>
>>
>> On 20/01/2025 11:29, Ard Biesheuvel wrote:
>>> On Mon, 20 Jan 2025 at 11:50, Usama Arif wrote:
On 20/01/2025 10:32, Ard Biesheuvel wrote:
> On Mon, 20 Jan 2025 at
On 09/01/2025 15:45, Ard Biesheuvel wrote:
> On Wed, 8 Jan 2025 at 23:00, Usama Arif wrote:
>>
>> The commit in [1] introduced a check to see if EFI memory attributes
>> table was corrupted. It assumed that efi.memmap.nr_map remains
>> constant, but it changes during late boot.
>> Hence, the ch
On 09/01/2025 16:15, Ard Biesheuvel wrote:
> On Wed, 8 Jan 2025 at 23:00, Usama Arif wrote:
>>
>> When this area is not reserved, it comes up as usable in
>> /sys/firmware/memmap. This means that kexec, which uses that memmap
>> to find usable memory regions, can select the region where
>> efi_
On 10/01/2025 02:50, Dave Young wrote:
> Hi Usama,
>
> On Thu, 9 Jan 2025 at 06:00, Usama Arif wrote:
>>
>> When this area is not reserved, it comes up as usable in
>> /sys/firmware/memmap. This means that kexec, which uses that memmap
>> to find usable memory regions, can select the region wh
On 10/01/2025 07:32, Ard Biesheuvel wrote:
> On Thu, 9 Jan 2025 at 17:32, Usama Arif wrote:
>>
>>
>>
>> On 09/01/2025 16:15, Ard Biesheuvel wrote:
>> I think in the end whoevers' responsibility it is, the easiest path forward
>> seems to be in kernel? (and not firmware or libstub)
>>
>
> Agre
On 10/01/2025 14:31, Usama Arif wrote:
>
>
> On 10/01/2025 07:32, Ard Biesheuvel wrote:
>> On Thu, 9 Jan 2025 at 17:32, Usama Arif wrote:
>>>
>>>
>>>
>>> On 09/01/2025 16:15, Ard Biesheuvel wrote:
>
>>> I think in the end whoevers' responsibility it is, the easiest path forward
>>> seems to
On 13/01/2025 11:27, Usama Arif wrote:
>
>
> On 13/01/2025 02:33, Dave Young wrote:
>> On Fri, 10 Jan 2025 at 18:54, Usama Arif wrote:
>>>
>>>
>>>
>>> On 10/01/2025 07:21, Ard Biesheuvel wrote:
On Thu, 9 Jan 2025 at 17:36, Usama Arif wrote:
>
>
>
> On 09/01/2025 15:45, A
On 13/01/2025 02:33, Dave Young wrote:
> On Fri, 10 Jan 2025 at 18:54, Usama Arif wrote:
>>
>>
>>
>> On 10/01/2025 07:21, Ard Biesheuvel wrote:
>>> On Thu, 9 Jan 2025 at 17:36, Usama Arif wrote:
On 09/01/2025 15:45, Ard Biesheuvel wrote:
> On Wed, 8 Jan 2025 at 23:00, U
On 10/01/2025 11:20, Dave Young wrote:
> On Fri, 10 Jan 2025 at 19:18, Dave Young wrote:
>>
>> On Fri, 10 Jan 2025 at 19:12, Usama Arif wrote:
>>>
>>>
>>>
>>> On 10/01/2025 02:50, Dave Young wrote:
Hi Usama,
On Thu, 9 Jan 2025 at 06:00, Usama Arif wrote:
>
> When this a
On 10/01/2025 07:21, Ard Biesheuvel wrote:
> On Thu, 9 Jan 2025 at 17:36, Usama Arif wrote:
>>
>>
>>
>> On 09/01/2025 15:45, Ard Biesheuvel wrote:
>>> On Wed, 8 Jan 2025 at 23:00, Usama Arif wrote:
The commit in [1] introduced a check to see if EFI memory attributes
table was co
13 matches
Mail list logo
