* [PATCH] efi/memreserve: register reservations as 'reserved' in /proc/iomem
@ 2019-12-04 14:52 Ard Biesheuvel
2019-12-04 17:17 ` Masayoshi Mizuma
0 siblings, 1 reply; 6+ messages in thread
From: Ard Biesheuvel @ 2019-12-04 14:52 UTC (permalink / raw)
To: linux-efi
Cc: mark.rutland, james.morse, Ard Biesheuvel, Masayoshi Mizuma,
d.hatayama, kexec
Memory regions that are reserved using efi_mem_reserve_persistent()
are recorded in a special EFI config table which survives kexec,
allowing the incoming kernel to honour them as well. However,
such reservations are not visible in /proc/iomem, and so the kexec
tools that load the incoming kernel and its initrd into memory may
overwrite these reserved regions before the incoming kernel has a
chance to reserve them from further use.
So add these reservations to /proc/iomem as they are created. Note
that reservations that are inherited from a previous kernel are
memblock_reserve()'d early on, so they are already visible in
/proc/iomem.
Cc: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
Cc: d.hatayama@fujitsu.com
Cc: kexec@lists.infradead.org
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
drivers/firmware/efi/efi.c | 29 ++++++++++++++++++--
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index d101f072c8f8..fcd82dde23c8 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -979,6 +979,24 @@ static int __init efi_memreserve_map_root(void)
return 0;
}
+static int efi_mem_reserve_iomem(phys_addr_t addr, u64 size)
+{
+ struct resource *res, *parent;
+
+ res = kzalloc(sizeof(struct resource), GFP_ATOMIC);
+ if (!res)
+ return -ENOMEM;
+
+ res->name = "reserved";
+ res->flags = IORESOURCE_MEM;
+ res->start = addr;
+ res->end = addr + size - 1;
+
+ /* we expect a conflict with a 'System RAM' region */
+ parent = request_resource_conflict(&iomem_resource, res);
+ return parent ? request_resource(parent, res) : 0;
+}
+
int __ref efi_mem_reserve_persistent(phys_addr_t addr, u64 size)
{
struct linux_efi_memreserve *rsv;
@@ -1001,9 +1019,8 @@ int __ref efi_mem_reserve_persistent(phys_addr_t addr, u64 size)
if (index < rsv->size) {
rsv->entry[index].base = addr;
rsv->entry[index].size = size;
-
memunmap(rsv);
- return 0;
+ return efi_mem_reserve_iomem(addr, size);
}
memunmap(rsv);
}
@@ -1013,6 +1030,12 @@ int __ref efi_mem_reserve_persistent(phys_addr_t addr, u64 size)
if (!rsv)
return -ENOMEM;
+ rc = efi_mem_reserve_iomem(__pa(rsv), SZ_4K);
+ if (rc) {
+ free_page(rsv);
+ return rc;
+ }
+
/*
* The memremap() call above assumes that a linux_efi_memreserve entry
* never crosses a page boundary, so let's ensure that this remains true
@@ -1029,7 +1052,7 @@ int __ref efi_mem_reserve_persistent(phys_addr_t addr, u64 size)
efi_memreserve_root->next = __pa(rsv);
spin_unlock(&efi_mem_reserve_persistent_lock);
- return 0;
+ return efi_mem_reserve_iomem(addr, size);
}
static int __init efi_memreserve_root_init(void)
--
2.17.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] efi/memreserve: register reservations as 'reserved' in /proc/iomem
2019-12-04 14:52 [PATCH] efi/memreserve: register reservations as 'reserved' in /proc/iomem Ard Biesheuvel
@ 2019-12-04 17:17 ` Masayoshi Mizuma
2019-12-04 18:17 ` James Morse
0 siblings, 1 reply; 6+ messages in thread
From: Masayoshi Mizuma @ 2019-12-04 17:17 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-efi, mark.rutland, james.morse, Masayoshi Mizuma,
d.hatayama, kexec
Hello Ard,
Thank you for sending the patch, but unfortunately it doesn't work for the issue...
After applied your patch, the LPI tables are marked as reserved in
/proc/iomem like as:
80300000-a1fdffff : System RAM
80480000-8134ffff : Kernel code
81350000-817bffff : reserved
817c0000-82acffff : Kernel data
830f0000-830fffff : reserved # Property table
83480000-83480fff : reserved # Pending table
83490000-8349ffff : reserved # Pending table
However, kexec tries to allocate memory from System RAM, it doesn't care
the reserved in System RAM.
Following example, kexec allocates memory 0x82ad0000-0x86640000 to locate
the initrd, and LPI tables are also in the memory region, so LPI tables
will be destroyed by kexec reboot.
# kexec -d -l /boot/vmlinuz-5.4.1+ --initrd=/boot/initramfs-5.4.1+.img
...
initrd: base 82ad0000, size 3b67c6fh (62291055)
...
segment[1].mem = 0x82ad0000
segment[1].memsz = 0x3b70000 # 0x86640000 (== 0x82ad0000 + 0x3b70000)
...
I'm not sure why kexec doesn't care the reserved in System RAM, however,
if the kexec behaivor is right, the LPI tables should not belong to
System RAM.
Like as:
80300000-830effff : System RAM
80480000-8134ffff : Kernel code
81350000-817bffff : reserved
817c0000-82acffff : Kernel data
830f0000-830fffff : reserved # Property table
83480000-83480fff : reserved # Pending table
83490000-8349ffff : reserved # Pending table
834a0000-a1fdffff : System RAM
I don't have ideas to separete LPI tables from System RAM... so I tried
to add a new file to inform the LPI tables to userspace.
Thanks,
Masa
On Wed, Dec 04, 2019 at 02:52:33PM +0000, Ard Biesheuvel wrote:
> Memory regions that are reserved using efi_mem_reserve_persistent()
> are recorded in a special EFI config table which survives kexec,
> allowing the incoming kernel to honour them as well. However,
> such reservations are not visible in /proc/iomem, and so the kexec
> tools that load the incoming kernel and its initrd into memory may
> overwrite these reserved regions before the incoming kernel has a
> chance to reserve them from further use.
>
> So add these reservations to /proc/iomem as they are created. Note
> that reservations that are inherited from a previous kernel are
> memblock_reserve()'d early on, so they are already visible in
> /proc/iomem.
>
> Cc: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
> Cc: d.hatayama@fujitsu.com
> Cc: kexec@lists.infradead.org
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
> drivers/firmware/efi/efi.c | 29 ++++++++++++++++++--
> 1 file changed, 26 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index d101f072c8f8..fcd82dde23c8 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -979,6 +979,24 @@ static int __init efi_memreserve_map_root(void)
> return 0;
> }
>
> +static int efi_mem_reserve_iomem(phys_addr_t addr, u64 size)
> +{
> + struct resource *res, *parent;
> +
> + res = kzalloc(sizeof(struct resource), GFP_ATOMIC);
> + if (!res)
> + return -ENOMEM;
> +
> + res->name = "reserved";
> + res->flags = IORESOURCE_MEM;
> + res->start = addr;
> + res->end = addr + size - 1;
> +
> + /* we expect a conflict with a 'System RAM' region */
> + parent = request_resource_conflict(&iomem_resource, res);
> + return parent ? request_resource(parent, res) : 0;
> +}
> +
> int __ref efi_mem_reserve_persistent(phys_addr_t addr, u64 size)
> {
> struct linux_efi_memreserve *rsv;
> @@ -1001,9 +1019,8 @@ int __ref efi_mem_reserve_persistent(phys_addr_t addr, u64 size)
> if (index < rsv->size) {
> rsv->entry[index].base = addr;
> rsv->entry[index].size = size;
> -
> memunmap(rsv);
> - return 0;
> + return efi_mem_reserve_iomem(addr, size);
> }
> memunmap(rsv);
> }
> @@ -1013,6 +1030,12 @@ int __ref efi_mem_reserve_persistent(phys_addr_t addr, u64 size)
> if (!rsv)
> return -ENOMEM;
>
> + rc = efi_mem_reserve_iomem(__pa(rsv), SZ_4K);
> + if (rc) {
> + free_page(rsv);
> + return rc;
> + }
> +
> /*
> * The memremap() call above assumes that a linux_efi_memreserve entry
> * never crosses a page boundary, so let's ensure that this remains true
> @@ -1029,7 +1052,7 @@ int __ref efi_mem_reserve_persistent(phys_addr_t addr, u64 size)
> efi_memreserve_root->next = __pa(rsv);
> spin_unlock(&efi_mem_reserve_persistent_lock);
>
> - return 0;
> + return efi_mem_reserve_iomem(addr, size);
> }
>
> static int __init efi_memreserve_root_init(void)
> --
> 2.17.1
>
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] efi/memreserve: register reservations as 'reserved' in /proc/iomem
2019-12-04 17:17 ` Masayoshi Mizuma
@ 2019-12-04 18:17 ` James Morse
2019-12-04 18:57 ` Masayoshi Mizuma
0 siblings, 1 reply; 6+ messages in thread
From: James Morse @ 2019-12-04 18:17 UTC (permalink / raw)
To: Masayoshi Mizuma, Ard Biesheuvel
Cc: linux-efi, mark.rutland, Masayoshi Mizuma, d.hatayama, kexec
Hi Masa,
On 04/12/2019 17:17, Masayoshi Mizuma wrote:
> Thank you for sending the patch, but unfortunately it doesn't work for the issue...
>
> After applied your patch, the LPI tables are marked as reserved in
> /proc/iomem like as:
>
> 80300000-a1fdffff : System RAM
> 80480000-8134ffff : Kernel code
> 81350000-817bffff : reserved
> 817c0000-82acffff : Kernel data
> 830f0000-830fffff : reserved # Property table
> 83480000-83480fff : reserved # Pending table
> 83490000-8349ffff : reserved # Pending table
>
> However, kexec tries to allocate memory from System RAM, it doesn't care
> the reserved in System RAM.
> I'm not sure why kexec doesn't care the reserved in System RAM, however,
Hmm, we added these to fix a problem with the UEFI memory map, and more recently ACPI
tables being overwritten by kexec.
Which version of kexec-tools are you using? Could you try:
https://git.linaro.org/people/takahiro.akashi/kexec-tools.git/commit/?h=arm64/resv_mem
> if the kexec behaivor is right, the LPI tables should not belong to
> System RAM.
> Like as:
>
> 80300000-830effff : System RAM
> 80480000-8134ffff : Kernel code
> 81350000-817bffff : reserved
> 817c0000-82acffff : Kernel data
> 830f0000-830fffff : reserved # Property table
> 83480000-83480fff : reserved # Pending table
> 83490000-8349ffff : reserved # Pending table
> 834a0000-a1fdffff : System RAM
>
> I don't have ideas to separete LPI tables from System RAM... so I tried
> to add a new file to inform the LPI tables to userspace.
This is how 'nomap' memory appears, we carve it out of System RAM. A side effect of this
is kdump can't touch it, as you've told it this isn't memory.
As these tables are memory, mapped by the linear map, I think Ard's patch is the right
thing to do ... I suspect your kexec-tools doesn't have those patches from Akashi to make
it honour all second level entries.
Thanks,
James
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] efi/memreserve: register reservations as 'reserved' in /proc/iomem
2019-12-04 18:17 ` James Morse
@ 2019-12-04 18:57 ` Masayoshi Mizuma
2019-12-04 20:13 ` Bhupesh SHARMA
0 siblings, 1 reply; 6+ messages in thread
From: Masayoshi Mizuma @ 2019-12-04 18:57 UTC (permalink / raw)
To: James Morse
Cc: Ard Biesheuvel, linux-efi, mark.rutland, Masayoshi Mizuma,
d.hatayama, kexec
On Wed, Dec 04, 2019 at 06:17:59PM +0000, James Morse wrote:
> Hi Masa,
>
> On 04/12/2019 17:17, Masayoshi Mizuma wrote:
> > Thank you for sending the patch, but unfortunately it doesn't work for the issue...
> >
> > After applied your patch, the LPI tables are marked as reserved in
> > /proc/iomem like as:
> >
> > 80300000-a1fdffff : System RAM
> > 80480000-8134ffff : Kernel code
> > 81350000-817bffff : reserved
> > 817c0000-82acffff : Kernel data
> > 830f0000-830fffff : reserved # Property table
> > 83480000-83480fff : reserved # Pending table
> > 83490000-8349ffff : reserved # Pending table
> >
> > However, kexec tries to allocate memory from System RAM, it doesn't care
> > the reserved in System RAM.
>
> > I'm not sure why kexec doesn't care the reserved in System RAM, however,
>
> Hmm, we added these to fix a problem with the UEFI memory map, and more recently ACPI
> tables being overwritten by kexec.
>
> Which version of kexec-tools are you using? Could you try:
> https://git.linaro.org/people/takahiro.akashi/kexec-tools.git/commit/?h=arm64/resv_mem
Thanks a lot! It worked and the issue is gone with Ard's patch and
the linaro kexec (arm64/resv_mem branch).
Ard, please feel free to add:
Tested-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
>
>
> > if the kexec behaivor is right, the LPI tables should not belong to
> > System RAM.
>
> > Like as:
> >
> > 80300000-830effff : System RAM
> > 80480000-8134ffff : Kernel code
> > 81350000-817bffff : reserved
> > 817c0000-82acffff : Kernel data
> > 830f0000-830fffff : reserved # Property table
> > 83480000-83480fff : reserved # Pending table
> > 83490000-8349ffff : reserved # Pending table
> > 834a0000-a1fdffff : System RAM
> >
> > I don't have ideas to separete LPI tables from System RAM... so I tried
> > to add a new file to inform the LPI tables to userspace.
>
> This is how 'nomap' memory appears, we carve it out of System RAM. A side effect of this
> is kdump can't touch it, as you've told it this isn't memory.
>
> As these tables are memory, mapped by the linear map, I think Ard's patch is the right
> thing to do ... I suspect your kexec-tools doesn't have those patches from Akashi to make
> it honour all second level entries.
I used the kexec on the top of master branch:
git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git
Should we use the linaro kexec for aarch64 machine?
Or will the arm64/resv_mem branch be merged to the kexec on
git.kernel.org...?
Thanks!
Masa
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] efi/memreserve: register reservations as 'reserved' in /proc/iomem
2019-12-04 18:57 ` Masayoshi Mizuma
@ 2019-12-04 20:13 ` Bhupesh SHARMA
2019-12-05 9:28 ` Ard Biesheuvel
0 siblings, 1 reply; 6+ messages in thread
From: Bhupesh SHARMA @ 2019-12-04 20:13 UTC (permalink / raw)
To: Masayoshi Mizuma
Cc: James Morse, Mark Rutland, Masayoshi Mizuma, linux-efi, kexec,
d.hatayama, Ard Biesheuvel, Simon Horman, Bhupesh Sharma
Hello Masa,
(+Cc Simon)
On Thu, Dec 5, 2019 at 12:27 AM Masayoshi Mizuma <msys.mizuma@gmail.com> wrote:
>
> On Wed, Dec 04, 2019 at 06:17:59PM +0000, James Morse wrote:
> > Hi Masa,
> >
> > On 04/12/2019 17:17, Masayoshi Mizuma wrote:
> > > Thank you for sending the patch, but unfortunately it doesn't work for the issue...
> > >
> > > After applied your patch, the LPI tables are marked as reserved in
> > > /proc/iomem like as:
> > >
> > > 80300000-a1fdffff : System RAM
> > > 80480000-8134ffff : Kernel code
> > > 81350000-817bffff : reserved
> > > 817c0000-82acffff : Kernel data
> > > 830f0000-830fffff : reserved # Property table
> > > 83480000-83480fff : reserved # Pending table
> > > 83490000-8349ffff : reserved # Pending table
> > >
> > > However, kexec tries to allocate memory from System RAM, it doesn't care
> > > the reserved in System RAM.
> >
> > > I'm not sure why kexec doesn't care the reserved in System RAM, however,
> >
> > Hmm, we added these to fix a problem with the UEFI memory map, and more recently ACPI
> > tables being overwritten by kexec.
> >
> > Which version of kexec-tools are you using? Could you try:
> > https://git.linaro.org/people/takahiro.akashi/kexec-tools.git/commit/?h=arm64/resv_mem
>
> Thanks a lot! It worked and the issue is gone with Ard's patch and
> the linaro kexec (arm64/resv_mem branch).
>
> Ard, please feel free to add:
>
> Tested-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
Same results at my side, so:
Tested-and-Reviewed-by: Bhipesh Sharma <bhsharma@redhat.com>
> >
> > > if the kexec behaivor is right, the LPI tables should not belong to
> > > System RAM.
> >
> > > Like as:
> > >
> > > 80300000-830effff : System RAM
> > > 80480000-8134ffff : Kernel code
> > > 81350000-817bffff : reserved
> > > 817c0000-82acffff : Kernel data
> > > 830f0000-830fffff : reserved # Property table
> > > 83480000-83480fff : reserved # Pending table
> > > 83490000-8349ffff : reserved # Pending table
> > > 834a0000-a1fdffff : System RAM
> > >
> > > I don't have ideas to separete LPI tables from System RAM... so I tried
> > > to add a new file to inform the LPI tables to userspace.
> >
> > This is how 'nomap' memory appears, we carve it out of System RAM. A side effect of this
> > is kdump can't touch it, as you've told it this isn't memory.
> >
> > As these tables are memory, mapped by the linear map, I think Ard's patch is the right
> > thing to do ... I suspect your kexec-tools doesn't have those patches from Akashi to make
> > it honour all second level entries.
>
> I used the kexec on the top of master branch:
> git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git
>
> Should we use the linaro kexec for aarch64 machine?
> Or will the arm64/resv_mem branch be merged to the kexec on
> git.kernel.org...?
Glad that Ard's patch fixes the issue for you.
Regarding Akashi's patch, I think it was sent to upstream kexec-tools
some time ago (see [0}) but seems not integrated in upstream
kexec-tools (now I noticed my Tested-by email for the same got bounced
off due to some gmail msmtp setting issues at my end - sorry for
that). I have added Simon in Cc list.
Hi Simon,
Can you please help pick [0] in upstream kexec-tools with Tested-by
from Masa and myself? Thanks a lot for your help.
[0]. http://lists.infradead.org/pipermail/kexec/2019-January/022201.html
Thanks,
Bhupesh
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] efi/memreserve: register reservations as 'reserved' in /proc/iomem
2019-12-04 20:13 ` Bhupesh SHARMA
@ 2019-12-05 9:28 ` Ard Biesheuvel
0 siblings, 0 replies; 6+ messages in thread
From: Ard Biesheuvel @ 2019-12-05 9:28 UTC (permalink / raw)
To: Bhupesh SHARMA
Cc: Masayoshi Mizuma, James Morse, Mark Rutland, Masayoshi Mizuma,
linux-efi, Kexec Mailing List, d.hatayama, Ard Biesheuvel,
Simon Horman, Bhupesh Sharma
On Wed, 4 Dec 2019 at 20:13, Bhupesh SHARMA <bhupesh.linux@gmail.com> wrote:
>
> Hello Masa,
>
> (+Cc Simon)
>
> On Thu, Dec 5, 2019 at 12:27 AM Masayoshi Mizuma <msys.mizuma@gmail.com> wrote:
> >
> > On Wed, Dec 04, 2019 at 06:17:59PM +0000, James Morse wrote:
> > > Hi Masa,
> > >
> > > On 04/12/2019 17:17, Masayoshi Mizuma wrote:
> > > > Thank you for sending the patch, but unfortunately it doesn't work for the issue...
> > > >
> > > > After applied your patch, the LPI tables are marked as reserved in
> > > > /proc/iomem like as:
> > > >
> > > > 80300000-a1fdffff : System RAM
> > > > 80480000-8134ffff : Kernel code
> > > > 81350000-817bffff : reserved
> > > > 817c0000-82acffff : Kernel data
> > > > 830f0000-830fffff : reserved # Property table
> > > > 83480000-83480fff : reserved # Pending table
> > > > 83490000-8349ffff : reserved # Pending table
> > > >
> > > > However, kexec tries to allocate memory from System RAM, it doesn't care
> > > > the reserved in System RAM.
> > >
> > > > I'm not sure why kexec doesn't care the reserved in System RAM, however,
> > >
> > > Hmm, we added these to fix a problem with the UEFI memory map, and more recently ACPI
> > > tables being overwritten by kexec.
> > >
> > > Which version of kexec-tools are you using? Could you try:
> > > https://git.linaro.org/people/takahiro.akashi/kexec-tools.git/commit/?h=arm64/resv_mem
> >
> > Thanks a lot! It worked and the issue is gone with Ard's patch and
> > the linaro kexec (arm64/resv_mem branch).
> >
> > Ard, please feel free to add:
> >
> > Tested-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
>
> Same results at my side, so:
> Tested-and-Reviewed-by: Bhipesh Sharma <bhsharma@redhat.com>
>
Thank you all. I'll get this queued as a fix with cc:stable for v5.4
> > >
> > > > if the kexec behaivor is right, the LPI tables should not belong to
> > > > System RAM.
> > >
> > > > Like as:
> > > >
> > > > 80300000-830effff : System RAM
> > > > 80480000-8134ffff : Kernel code
> > > > 81350000-817bffff : reserved
> > > > 817c0000-82acffff : Kernel data
> > > > 830f0000-830fffff : reserved # Property table
> > > > 83480000-83480fff : reserved # Pending table
> > > > 83490000-8349ffff : reserved # Pending table
> > > > 834a0000-a1fdffff : System RAM
> > > >
> > > > I don't have ideas to separete LPI tables from System RAM... so I tried
> > > > to add a new file to inform the LPI tables to userspace.
> > >
> > > This is how 'nomap' memory appears, we carve it out of System RAM. A side effect of this
> > > is kdump can't touch it, as you've told it this isn't memory.
> > >
> > > As these tables are memory, mapped by the linear map, I think Ard's patch is the right
> > > thing to do ... I suspect your kexec-tools doesn't have those patches from Akashi to make
> > > it honour all second level entries.
> >
> > I used the kexec on the top of master branch:
> > git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git
> >
> > Should we use the linaro kexec for aarch64 machine?
> > Or will the arm64/resv_mem branch be merged to the kexec on
> > git.kernel.org...?
>
> Glad that Ard's patch fixes the issue for you.
> Regarding Akashi's patch, I think it was sent to upstream kexec-tools
> some time ago (see [0}) but seems not integrated in upstream
> kexec-tools (now I noticed my Tested-by email for the same got bounced
> off due to some gmail msmtp setting issues at my end - sorry for
> that). I have added Simon in Cc list.
>
> Hi Simon,
>
> Can you please help pick [0] in upstream kexec-tools with Tested-by
> from Masa and myself? Thanks a lot for your help.
>
> [0]. http://lists.infradead.org/pipermail/kexec/2019-January/022201.html
>
> Thanks,
> Bhupesh
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-12-05 9:28 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-04 14:52 [PATCH] efi/memreserve: register reservations as 'reserved' in /proc/iomem Ard Biesheuvel
2019-12-04 17:17 ` Masayoshi Mizuma
2019-12-04 18:17 ` James Morse
2019-12-04 18:57 ` Masayoshi Mizuma
2019-12-04 20:13 ` Bhupesh SHARMA
2019-12-05 9:28 ` Ard Biesheuvel
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).