Am 01.11.2011 07:28, schrieb Dan Carpenter: > I assume the the check on if (limit <= prv) prevents n_tads from > actually reaching MAX_TAD. The problem with that is that it relies > on the hardware returning the right value and Smatch complains that > if it doesn't we could have a buffer overflow. > > Signed-off-by: Dan Carpenter <dan.carpenter@xxxxxxxxxx> > --- > Feel free to ignore this patch if you want. I don't have very stong > feelings about this either way. > > diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c > index 7a402bf..ebf386c 100644 > --- a/drivers/edac/sb_edac.c > +++ b/drivers/edac/sb_edac.c > @@ -970,6 +970,12 @@ static int get_memory_error_data(struct mem_ctl_info *mci, > break; > prv = limit; > } > + if (n_tads == MAX_TAD) { > + sprintf(msg, "Could not discover the memory channel"); why the sprintf() ? can you not simply: edac_mc_handle_ce_no_info(mci,"Could not discover the memory channel"); re, wh > + edac_mc_handle_ce_no_info(mci, msg); > + return -EINVAL; > + } > + > ch_way = TAD_CH(reg) + 1; > sck_way = TAD_SOCK(reg) + 1; > /* -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html