3.2.63-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Aaro Koskinen <aaro.koskinen@xxxxxxx> commit 608308682addfdc7b8e2aee88f0e028331d88e4d upstream. get_system_type() is not thread-safe on OCTEON. It uses static data, also more dangerous issue is that it's calling cvmx_fuse_read_byte() every time without any synchronization. Currently it's possible to get processes stuck looping forever in kernel simply by launching multiple readers of /proc/cpuinfo: (while true; do cat /proc/cpuinfo > /dev/null; done) & (while true; do cat /proc/cpuinfo > /dev/null; done) & ... Fix by initializing the system type string only once during the early boot. Signed-off-by: Aaro Koskinen <aaro.koskinen@xxxxxxx> Reviewed-by: Markos Chandras <markos.chandras@xxxxxxxxxx> Patchwork: http://patchwork.linux-mips.org/patch/7437/ Signed-off-by: James Hogan <james.hogan@xxxxxxxxxx> Signed-off-by: Ben Hutchings <ben@xxxxxxxxxxxxxxx> --- arch/mips/cavium-octeon/setup.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) --- a/arch/mips/cavium-octeon/setup.c +++ b/arch/mips/cavium-octeon/setup.c @@ -266,6 +266,18 @@ static irqreturn_t octeon_rlm_interrupt( } #endif +static char __read_mostly octeon_system_type[80]; + +static int __init init_octeon_system_type(void) +{ + snprintf(octeon_system_type, sizeof(octeon_system_type), "%s (%s)", + cvmx_board_type_to_string(octeon_bootinfo->board_type), + octeon_model_get_string(read_c0_prid())); + + return 0; +} +early_initcall(init_octeon_system_type); + /** * Return a string representing the system type * @@ -273,11 +285,7 @@ static irqreturn_t octeon_rlm_interrupt( */ const char *octeon_board_type_string(void) { - static char name[80]; - sprintf(name, "%s (%s)", - cvmx_board_type_to_string(octeon_bootinfo->board_type), - octeon_model_get_string(read_c0_prid())); - return name; + return octeon_system_type; } const char *get_system_type(void) -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html