On Wed, Oct 25, 2023 at 04:12:37PM +0100, Abdellatif El Khlifi wrote: > Hi Tom, > > > > > ________________________________________________________________________________________________________ > > > > *** CID 464361: Control flow issues (DEADCODE) > > > > /drivers/firmware/arm-ffa/arm-ffa-uclass.c: 148 in ffa_print_error_log() > > > > 142 > > > > 143 if (ffa_id < FFA_FIRST_ID || ffa_id > FFA_LAST_ID) > > > > 144 return -EINVAL; > > > > 145 > > > > 146 abi_idx = FFA_ID_TO_ERRMAP_ID(ffa_id); > > > > 147 if (abi_idx < 0 || abi_idx >= FFA_ERRMAP_COUNT) > > > > >>> CID 464361: Control flow issues (DEADCODE) > > > > >>> Execution cannot reach this statement: "return -22;". > > > > 148 return -EINVAL; > > > > > > This is a false positive. > > > > > > abi_idx value could end up matching this condition "(abi_idx < 0 || > > > abi_idx >= FFA_ERRMAP_COUNT)". > > > > > > This happens when ffa_id value is above the allowed bounds. Example: when > > > ffa_id is 0x50 or 0x80 > > > > > > ffa_print_error_log(0x50, ...); /* exceeding lower bound */ > > > ffa_print_error_log(0x80, ...); /* exceeding upper bound */ > > > > > > In these cases "return -EINVAL;" is executed. > > > > So those invalid values aren't caught by the previous check that ffa_id > > falls within FFA_FIRST_ID to FFA_LAST_ID ? > > I had a closer look at that and I agree that the deadcode defect is > legitimate. > I already provided a fix [1]. > > [1]: > https://lore.kernel.org/all/20231020131533.239591-1-abdellatif.elkhl...@arm.com/
Ah thanks. I had seen that posted but not put that together with this email and assumed it was addressing something you hadn't talked about here because you agreed with it being an issue. I will pick up the above patch soon then. -- Tom
signature.asc
Description: PGP signature