On Wed, Oct 02, 2024 at 12:22:48PM -0700, Nicolin Chen wrote:
On Wed, Oct 02, 2024 at 12:04:32PM -0700, Yang Shi wrote:It would make some sense to have something like:
Yea, and looks like we are going to do with:On Wed, Oct 02, 2024 at 10:55:14AM -0700, Yang Shi wrote:No particular reason, but it should be better to not truncate here. Will
+static inline unsigned int arm_smmu_strtab_max_sid(struct arm_smmu_device *smmu)Hmm, why ULL gets truncated to unsigned int here?
+{
+ return (1ULL << smmu->sid_bits);
+}
+
fix it.
static inline u64 arm_smmu_strtab_num_sids(struct arm_smmu_device *smmu);
Then let's be careful at those return-value holders too:
-----------------------------------------------------------
static int arm_smmu_init_strtab_linear(struct arm_smmu_device *smmu)
{
u32 size;
struct arm_smmu_strtab_cfg *cfg = &smmu->strtab_cfg;
size = (1 << smmu->sid_bits) * sizeof(struct arm_smmu_ste);
^^^^
overflow?
[...]
cfg->linear.num_ents = 1 << smmu->sid_bits;
^^^^^^^^
This is u32
-----------------------------------------------------------
u64 size = arm_smmu_strtab_max_sid()
/* Would require too much memory */
if (size > SZ_512M)
return -EINVAL;
Just to reject bad configuration rather than truncate the allocation
and overflow STE array memory or something. Having drivers be robust
to this kind of stuff is a confidential compute topic :\
Jason