| Message ID | 20220425171526.44925-6-martin.fernandez@eclypsium.com |
|---|---|
| State | New |
| Headers | show |
| Series | [v7,1/8] mm/memblock: Tag memblocks with crypto capabilities | expand |
On 4/25/22 10:15, Martin Fernandez wrote: > +/** > + * e820__range_remove() - Remove an address range from e820_table. > + * @start: Start of the address range. > + * @size: Size of the address range. > + * @old_type: Type of the entries that we want to remove. > + * @check_type: Bool to decide if ignore @old_type or not. > + * > + * Remove [@start, @start + @size) from e820_table. If @check_type is > + * true remove only entries with type @old_type. > + * > + * Return: The size removed. > + */ The refactoring looks promising. But, there's a *LOT* of kerneldoc noise, like: > + * @table: Target e820_table. > + * @start: Start of the range. > + * @size: Size of the range. and this: > + * struct e820_type_updater_data - Helper type for > + * __e820__range_update(). > + * @old_type: old_type parameter of __e820__range_update(). > + * @new_type: new_type parameter of __e820__range_update(). Those are just a pure waste of bytes. I suspect some more judicious function comments would also make the diffstat look more palatable. Also, in general, the naming is a bit verbose. You might want to trim some of those names down, like: > +static bool __init crypto_updater__should_update(const struct e820_entry *entry, > + const void *data) > +{ > + const struct e820_crypto_updater_data *crypto_updater_data = > + (const struct e820_crypto_updater_data *)data; Those are just some high-level comments. This also needs some really careful review of the refactoring to make sure that it doesn't break any of the existing e820 users.
On 4/26/22, Dave Hansen <dave.hansen@intel.com> wrote: > On 4/25/22 10:15, Martin Fernandez wrote: >> +/** >> + * e820__range_remove() - Remove an address range from e820_table. >> + * @start: Start of the address range. >> + * @size: Size of the address range. >> + * @old_type: Type of the entries that we want to remove. >> + * @check_type: Bool to decide if ignore @old_type or not. >> + * >> + * Remove [@start, @start + @size) from e820_table. If @check_type is >> + * true remove only entries with type @old_type. >> + * >> + * Return: The size removed. >> + */ > > The refactoring looks promising. But, there's a *LOT* of kerneldoc > noise, like: > >> + * @table: Target e820_table. >> + * @start: Start of the range. >> + * @size: Size of the range. > > and this: > >> + * struct e820_type_updater_data - Helper type for >> + * __e820__range_update(). >> + * @old_type: old_type parameter of __e820__range_update(). >> + * @new_type: new_type parameter of __e820__range_update(). > > Those are just a pure waste of bytes. I suspect some more judicious > function comments would also make the diffstat look more palatable. > I can get rid off of the kerneldocs and just put normal comments for some functions that really need them. > Also, in general, the naming is a bit verbose. You might want to trim > some of those names down, like: > >> +static bool __init crypto_updater__should_update(const struct e820_entry >> *entry, >> + const void *data) >> +{ >> + const struct e820_crypto_updater_data *crypto_updater_data = >> + (const struct e820_crypto_updater_data *)data; > Yes I agree on this. Do you have any suggestions for these kind of functions? I want to explicitly state that these functions are in some of namespace and are different of the other ones. In the end I don't think this is very harmful since these functions are one-time used (in a single place), is not the case that you have to use them everywhere.. > Those are just some high-level comments. This also needs some really > careful review of the refactoring to make sure that it doesn't break any > of the existing e820 users. > I'm glad to hear more people's thoughts on this. Thanks for the feedback.
On 4/26/22 10:37, Martin Fernandez wrote: >> Also, in general, the naming is a bit verbose. You might want to trim >> some of those names down, like: >> >>> +static bool __init crypto_updater__should_update(const struct e820_entry >>> *entry, >>> + const void *data) >>> +{ >>> + const struct e820_crypto_updater_data *crypto_updater_data = >>> + (const struct e820_crypto_updater_data *)data; > Yes I agree on this. Do you have any suggestions for these kind of > functions? I want to explicitly state that these functions are in some of > namespace and are different of the other ones. > > In the end I don't think this is very harmful since these functions are one-time > used (in a single place), is not the case that you have to use them everywhere.. Let's just start with the fact that this is a pointer to a structure containing an enum that represents a single bit. You could just pass around an address to a bool: bool crypto_capable = *(bool *)data; or even just pass and use the 'void *data' pointer as a value directly: bool crypto_capable = (bool)data; That, for one, would get rid of some of the naming craziness. If it were me, and I *really* wanted to keep the full types, I would have just condensed that line down to: struct e820_crypto_updater_data *crypto_data = data; Yeah, it _can_ be const, but it buys you practically nothing in this case and only hurts readability.
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index 763b8b20a1fd..9e32c9819e99 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -717,66 +717,74 @@ static u64 __init e820__range_update_kexec(u64 start, u64 size, return __e820__range_update(e820_table_kexec, start, size, old_type, new_type); } -/* Remove a range of memory from the E820 table: */ -u64 __init e820__range_remove(u64 start, u64 size, enum e820_type old_type, bool check_type) -{ - int i; - u64 end; - u64 real_removed_size = 0; - - if (size > (ULLONG_MAX - start)) - size = ULLONG_MAX - start; - - end = start + size; - printk(KERN_DEBUG "e820: remove [mem %#010Lx-%#010Lx] ", start, end - 1); - if (check_type) - e820_print_type(old_type); - pr_cont("\n"); - - for (i = 0; i < e820_table->nr_entries; i++) { - struct e820_entry *entry = &e820_table->entries[i]; - u64 final_start, final_end; - u64 entry_end; +/** + * struct e820_remover_data - Helper type for e820__range_remove(). + * @old_type: old_type parameter of e820__range_remove(). + * @check_type: check_type parameter of e820__range_remove(). + * + * This is intended to be used as the @data argument for the + * e820_entry_updater callbacks. + */ +struct e820_remover_data { + enum e820_type old_type; + bool check_type; +}; - if (check_type && entry->type != old_type) - continue; +static bool __init remover__should_update(const struct e820_entry *entry, + const void *data) +{ + const struct e820_remover_data *remover_data = + (const struct e820_remover_data *)data; - entry_end = entry->addr + entry->size; + return !remover_data->check_type || + entry->type == remover_data->old_type; +} - /* Completely covered? */ - if (entry->addr >= start && entry_end <= end) { - real_removed_size += entry->size; - memset(entry, 0, sizeof(*entry)); - continue; - } +static void __init remover__update(struct e820_entry *entry, const void *data) +{ + memset(entry, 0, sizeof(*entry)); +} - /* Is the new range completely covered? */ - if (entry->addr < start && entry_end > end) { - e820__range_add(end, entry_end - end, entry->type); - entry->size = start - entry->addr; - real_removed_size += size; - continue; - } +static void __init remover__new(struct e820_table *table, u64 new_start, + u64 new_size, const struct e820_entry *original, + const void *data) +{ +} - /* Partially covered: */ - final_start = max(start, entry->addr); - final_end = min(end, entry_end); - if (final_start >= final_end) - continue; +/** + * e820__range_remove() - Remove an address range from e820_table. + * @start: Start of the address range. + * @size: Size of the address range. + * @old_type: Type of the entries that we want to remove. + * @check_type: Bool to decide if ignore @old_type or not. + * + * Remove [@start, @start + @size) from e820_table. If @check_type is + * true remove only entries with type @old_type. + * + * Return: The size removed. + */ +u64 __init e820__range_remove(u64 start, u64 size, enum e820_type old_type, + bool check_type) +{ + struct e820_entry_updater updater = { + .should_update = remover__should_update, + .update = remover__update, + .new = remover__new + }; - real_removed_size += final_end - final_start; + struct e820_remover_data data = { + .check_type = check_type, + .old_type = old_type + }; - /* - * Left range could be head or tail, so need to update - * the size first: - */ - entry->size -= final_end - final_start; - if (entry->addr < final_start) - continue; + printk(KERN_DEBUG "e820: remove [mem %#018Lx-%#018Lx] ", start, + start + size - 1); + if (check_type) + e820_print_type(old_type); + pr_cont("\n"); - entry->addr = final_end; - } - return real_removed_size; + return __e820__handle_range_update(e820_table, start, size, &updater, + &data); } void __init e820__update_table_print(void)
Refactor e820__range_remove with the introduction of e820_remover_data, indented to be used as the void pointer in the e820_entry_updater callbacks, and the implementation of the callbacks remove a range in the e820_table. Signed-off-by: Martin Fernandez <martin.fernandez@eclypsium.com> --- arch/x86/kernel/e820.c | 112 ++++++++++++++++++++++------------------- 1 file changed, 60 insertions(+), 52 deletions(-)