On May 28, 2016, at 7:34 AM, Dan Carpenter wrote: > On Fri, May 20, 2016 at 02:21:25PM -0400, Oleg Drokin wrote: >> Hello! >> >> I am bringing this up again since it's still a problem. >> I have this memory of you sending an alternative patch that did not clone the whole state, >> but instead just updated the line number for the derivative. >> >> Anyway, neither one made it to the tree and I think this is better be fixed one way or the other? >> What do you think? > > I just pushed a change that might help? Otherwise could you send me a > test case again? I seem to have lost the previous one. Did not help. I do not have a small formalized testcase, but the real world example is e.g. here: http://git.whamcloud.com/fs/lustre-release.git/blob/943612ac470a1f916d44f551eee01c3d51fc9546:/lustre/lfsck/lfsck_layout.c The diff in the output (from with the patch to without) is: -lustre/lfsck/lfsck_layout.c:2390 lfsck_layout_recreate_lovea() warn: variable dereferenced before check 'handle' (see line 2242) -lustre/lfsck/lfsck_layout.c:2415 lfsck_layout_recreate_lovea() warn: variable dereferenced before check 'handle' (see line 2242) +lustre/lfsck/lfsck_layout.c:2390 lfsck_layout_recreate_lovea() warn: variable dereferenced before check 'handle' (see line 2386) +lustre/lfsck/lfsck_layout.c:2415 lfsck_layout_recreate_lovea() warn: variable dereferenced before check 'handle' (see line 2411) You can see how the new "state" that's resultant from the "merge" of the previous if gets the new line number at the place of merge. Your idea of just looking at line numbers and assigning older one if it was the same (or there was no new state created so one side of the merge is empty) might be workable, but I feel like the more state might be needed, that's why I "cloned" one of the states instead and I seem to be having good results so far. Bye, Oleg-- To unsubscribe from this list: send the line "unsubscribe smatch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
