> From: Jan Beulich <jbeul...@suse.com> > Sent: Friday, March 3, 2023 3:32 PM > > Switches of altp2m-s always expect a valid altp2m to be in place (and > indeed altp2m_vcpu_initialise() sets the active one to be at index 0). > The compiler, however, cannot know that, and hence it cannot eliminate > p2m_get_altp2m()'s case of returnin (literal) NULL. If then the compiler > decides to special case that code path in the caller, the dereference in > instances of > > atomic_dec(&p2m_get_altp2m(v)->active_vcpus); > > can, to the code generator, appear to be NULL dereferences, leading to > > In function 'atomic_dec', > inlined from '...' at ...: > ./arch/x86/include/asm/atomic.h:182:5: error: array subscript 0 is outside > array bounds of 'int[0]' [-Werror=array-bounds=] > > Aid the compiler by adding a BUG_ON() checking the return value of the > problematic p2m_get_altp2m(). Since with the use of the local variable > the 2nd p2m_get_altp2m() each will look questionable at the first glance > (Why is the local variable not used here?), open-code the only relevant > piece of p2m_get_altp2m() there. > > To avoid repeatedly doing these transformations, and also to limit how > "bad" the open-coding really is, convert the entire operation to an > inline helper, used by all three instances (and accepting the redundant > BUG_ON(idx >= MAX_ALTP2M) in two of the three cases). > > Reported-by: Charles Arnold <carn...@suse.com> > Signed-off-by: Jan Beulich <jbeul...@suse.com> >
Reviewed-by: Kevin Tian <kevin.t...@intel.com>
