On 11.07.2025 09:25, dm...@proton.me wrote: > On Fri, Jul 11, 2025 at 07:59:27AM +0200, Jan Beulich wrote: >> On 11.07.2025 03:07, dm...@proton.me wrote: >>> On Thu, Jul 10, 2025 at 01:16:24PM +0200, Jan Beulich wrote: >>>> On 10.07.2025 03:35, dm...@proton.me wrote: >>>>> @@ -877,6 +873,16 @@ struct domain *domain_create(domid_t domid, >>>>> >>>>> /* All error paths can depend on the above setup. */ >>>>> >>>>> + BUILD_BUG_ON(DOMAIN_CONSOLE_BUF_SIZE <= 0); >>>> >>>> While the "equals 0" case can in principle happen, the "less than" part >>>> is dead code (and hence this needs checking differently): The type of >>>> DOMAIN_CONSOLE_BUF_SIZE is an unsigned one, so wrapping through 0 will >>>> yield huge positive values. >>>> >>>>> + err = -ENOMEM; >>>>> + d->console = xzalloc_bytes(DOMAIN_CONSOLE_SIZE); >>>> >>>> As previously indicated, new code ought to use the xv*alloc family of >>>> functions, which deliberately doesn't include any ..._bytes() forms. >>>> Note how instead there is xvzalloc_flex_struct() for situations like >>>> the one here. >>> >>> Looks like xvzalloc_flex_struct() is not used anywhere in the code base... >> >> And what do you mean to tell me by that? xvmalloc_flex_struct() is used, >> and x[mz]alloc_flex_struct() uses are still in need of conversion (which >> is going to be a slow-going process). > > Just an observation; I was not aware of these APIs and I was not aware that > there's some slow-going process of switching to preferred use of > xvzalloc_flex_struct().
The ongoing conversion is (more generally) from x[mz]alloc family of functions to the xv[mz]alloc one, as is made explicit by the comment near the top of xvmalloc.h. Jan
