On Thursday 17 September 2015 07:16:44 Pavel Machek wrote: > > > > if (image->depth == 1) { > > > if (p->fix.visual == FB_VISUAL_TRUECOLOR || > > > p->fix.visual == FB_VISUAL_DIRECTCOLOR) { > > > fgcolor = ((u32*)(p->pseudo_palette))[image->fg_color]; > > > bgcolor = ((u32*)(p->pseudo_palette))[image->bg_color]; > > > } else { > > > fgcolor = image->fg_color; > > > bgcolor = image->bg_color; > > > } > > > > > > if (32 % bpp == 0 && !start_index && !pitch_index && > > > ((width & (32/bpp-1)) == 0) && > > > bpp >= 8 && bpp <= 32) > > > fast_imageblit(image, p, dst1, fgcolor, bgcolor); > > > else > > > slow_imageblit(image, p, dst1, fgcolor, bgcolor, > > > start_index, pitch_index); > > > } else > > > color_imageblit(image, p, dst1, start_index, pitch_i > > > > > > > > > Notice that bpp is not checked for zero, and thus bpp==0 is totally > > > feasible? resulting in 32/bpp crashing the kernel? > > > > > > > Hm... this could really be a problem! But how to patch it? Which branch > > should be called (fast_ or slow_ function) if bpp is zero? > > > > And is there some way to force kernel to dump backtrace into dmesg when > > division by zero occur? > > You can do WARN_ON(bpp==1) ... and should probably return in that > case. > > Pavel Does not make sense to call slow_ function? In that if condition check also that bpp is nonzero... -- Pali Rohár pali.rohar@xxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html