| Message ID | 1455696653-27023-1-git-send-email-k.kozlowski@samsung.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
Hi, > -----Original Message----- > From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel- > owner@vger.kernel.org] On Behalf Of Krzysztof Kozlowski > Sent: Wednesday, February 17, 2016 12:11 AM > To: Sangbeom Kim <sbkim73@samsung.com>; Krzysztof Kozlowski > <k.kozlowski@samsung.com>; Liam Girdwood <lgirdwood@gmail.com>; > Mark Brown <broonie@kernel.org>; linux-kernel@vger.kernel.org; linux- > samsung-soc@vger.kernel.org > Cc: Arnd Bergmann <arnd@arndb.de> > Subject: [RFT] regulator: s2mps11: Simplify expression used in > BUILD_BUG_ON for some of preprocessors > > Apparently some preprocessors have problems with interpreting > BUILD_BUG_ON such as: > var = ARRAY_SIZE(s2mps15_regulators); > BUILD_BUG_ON(S2MPS_REGULATOR_MAX < var); > so let make it more obvious for them. > Doesn't have much to do with the preprocessor, but rather exactly how the compiler optimizes the variable. Some kernel configurations also impact this, and it heavily depends on whether the compiler actually optimizes away the variable. BUILD_BUG_ON may work a lot of the time, depending heavily on the compiler. BUILD_BUG_ON only works for constant expressions, so it is safer to put the value in directly, because using a variable will only work if the compiler optimizes the use of a variable away entirely. In this case it is somewhat surprising that it doesn't, but would depend on what compiler version and what kernel build rules you were using. For example allmodconfig ends up selecting everything yes if it's not a module for kernel build options and results in some BUILD_BUG_ON failures because of that) Thanks, Jake -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 18.02.2016 05:37, Keller, Jacob E wrote: > Hi, > >> -----Original Message----- >> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel- >> owner@vger.kernel.org] On Behalf Of Krzysztof Kozlowski >> Sent: Wednesday, February 17, 2016 12:11 AM >> To: Sangbeom Kim <sbkim73@samsung.com>; Krzysztof Kozlowski >> <k.kozlowski@samsung.com>; Liam Girdwood <lgirdwood@gmail.com>; >> Mark Brown <broonie@kernel.org>; linux-kernel@vger.kernel.org; linux- >> samsung-soc@vger.kernel.org >> Cc: Arnd Bergmann <arnd@arndb.de> >> Subject: [RFT] regulator: s2mps11: Simplify expression used in >> BUILD_BUG_ON for some of preprocessors >> >> Apparently some preprocessors have problems with interpreting >> BUILD_BUG_ON such as: >> var = ARRAY_SIZE(s2mps15_regulators); >> BUILD_BUG_ON(S2MPS_REGULATOR_MAX < var); >> so let make it more obvious for them. >> > > Doesn't have much to do with the preprocessor, but rather exactly how the compiler optimizes the variable. Some kernel configurations also impact this, and it heavily depends on whether the compiler actually optimizes away the variable. BUILD_BUG_ON may work a lot of the time, depending heavily on the compiler. > > BUILD_BUG_ON only works for constant expressions, so it is safer to put the value in directly, because using a variable will only work if the compiler optimizes the use of a variable away entirely. In this case it is somewhat surprising that it doesn't, but would depend on what compiler version and what kernel build rules you were using. For example allmodconfig ends up selecting everything yes if it's not a module for kernel build options and results in some BUILD_BUG_ON failures because of that) Right, thanks for detailed explanation. Arnd confirmed that patch fixes encountered issue (gcc 4.9 with UBSAN). I'll change the commit message and re-submit. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c index 3242ffc0cb25..df553fb40d82 100644 --- a/drivers/regulator/s2mps11.c +++ b/drivers/regulator/s2mps11.c @@ -1090,26 +1090,27 @@ static int s2mps11_pmic_probe(struct platform_device *pdev) case S2MPS11X: s2mps11->rdev_num = ARRAY_SIZE(s2mps11_regulators); regulators = s2mps11_regulators; - BUILD_BUG_ON(S2MPS_REGULATOR_MAX < s2mps11->rdev_num); + BUILD_BUG_ON(S2MPS_REGULATOR_MAX < ARRAY_SIZE(s2mps11_regulators)); break; case S2MPS13X: s2mps11->rdev_num = ARRAY_SIZE(s2mps13_regulators); regulators = s2mps13_regulators; - BUILD_BUG_ON(S2MPS_REGULATOR_MAX < s2mps11->rdev_num); + BUILD_BUG_ON(S2MPS_REGULATOR_MAX < ARRAY_SIZE(s2mps13_regulators)); break; case S2MPS14X: s2mps11->rdev_num = ARRAY_SIZE(s2mps14_regulators); regulators = s2mps14_regulators; - BUILD_BUG_ON(S2MPS_REGULATOR_MAX < s2mps11->rdev_num); + BUILD_BUG_ON(S2MPS_REGULATOR_MAX < ARRAY_SIZE(s2mps14_regulators)); break; case S2MPS15X: s2mps11->rdev_num = ARRAY_SIZE(s2mps15_regulators); regulators = s2mps15_regulators; + BUILD_BUG_ON(S2MPS_REGULATOR_MAX < ARRAY_SIZE(s2mps15_regulators)); break; case S2MPU02: s2mps11->rdev_num = ARRAY_SIZE(s2mpu02_regulators); regulators = s2mpu02_regulators; - BUILD_BUG_ON(S2MPS_REGULATOR_MAX < s2mps11->rdev_num); + BUILD_BUG_ON(S2MPS_REGULATOR_MAX < ARRAY_SIZE(s2mpu02_regulators)); break; default: dev_err(&pdev->dev, "Invalid device type: %u\n",
Apparently some preprocessors have problems with interpreting BUILD_BUG_ON such as: var = ARRAY_SIZE(s2mps15_regulators); BUILD_BUG_ON(S2MPS_REGULATOR_MAX < var); so let make it more obvious for them. Additionally add missing BUILD_BUG_ON check for S2MPS15 device (the check ensures that internal arrays are big enough to hold data for all of regulators on all devices). Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> --- See results when UBSAN is enabled: http://arm-soc.lixom.net/buildlogs/arm-soc/v4.5-rc4-39-g0d7baf0/buildall.arm.exynos_defconfig.log.failed --- drivers/regulator/s2mps11.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)