| Message ID | 20190430025347.3097-2-erosca@de.adit-jv.com |
|---|---|
| State | Superseded |
| Delegated to: | Heinrich Schuchardt |
| Headers | show |
| Series | Misc EFI/GPT/UUID fixes | expand |
On 4/30/19 4:53 AM, Eugeniu Rosca wrote: > Below is what happens on R-Car H3ULCB-KF using clean U-Boot > v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: > > => ### interrupt autoboot > => gpt guid mmc 1 > 21200400-0804-0146-9dcc-a8c51255994f > success! > => ### keep calling 'gpt guid mmc 1' > => ### on 59th call, we are out of memory: > => gpt guid mmc 1 > alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries > GPT: Failed to allocate memory for PTE > get_disk_guid: *** ERROR: Invalid GPT *** > alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries > GPT: Failed to allocate memory for PTE > get_disk_guid: *** ERROR: Invalid Backup GPT *** > error! > > After some inspection, it looks like get_disk_guid(), added via v2017.09 > commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), > unlike other callers of is_gpt_valid(), doesn't free the memory pointed > out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() > via alloc_read_gpt_entries(). > > With the fix applied, the reproduction scenario has been run hundreds > of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. > > Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") > Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> > --- > disk/part_efi.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/disk/part_efi.c b/disk/part_efi.c > index 239455b8161e..812d14cdd871 100644 > --- a/disk/part_efi.c > +++ b/disk/part_efi.c > @@ -209,6 +209,8 @@ int get_disk_guid(struct blk_desc * dev_desc, char *guid) > guid_bin = gpt_head->disk_guid.b; > uuid_bin_to_str(guid_bin, guid, UUID_STR_FORMAT_GUID); > > + /* Remember to free pte */ > + free(gpt_pte); > return 0; > } > >
diff --git a/disk/part_efi.c b/disk/part_efi.c index 239455b8161e..812d14cdd871 100644 --- a/disk/part_efi.c +++ b/disk/part_efi.c @@ -209,6 +209,8 @@ int get_disk_guid(struct blk_desc * dev_desc, char *guid) guid_bin = gpt_head->disk_guid.b; uuid_bin_to_str(guid_bin, guid, UUID_STR_FORMAT_GUID); + /* Remember to free pte */ + free(gpt_pte); return 0; }
Below is what happens on R-Car H3ULCB-KF using clean U-Boot v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig: => ### interrupt autoboot => gpt guid mmc 1 21200400-0804-0146-9dcc-a8c51255994f success! => ### keep calling 'gpt guid mmc 1' => ### on 59th call, we are out of memory: => gpt guid mmc 1 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid GPT *** alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries GPT: Failed to allocate memory for PTE get_disk_guid: *** ERROR: Invalid Backup GPT *** error! After some inspection, it looks like get_disk_guid(), added via v2017.09 commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"), unlike other callers of is_gpt_valid(), doesn't free the memory pointed out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid() via alloc_read_gpt_entries(). With the fix applied, the reproduction scenario has been run hundreds of times ('while true; do gpt guid mmc 1; done') w/o running into OOM. Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> --- disk/part_efi.c | 2 ++ 1 file changed, 2 insertions(+)