I'm having a hard time getting the lustre sources to build on debian. I'm just getting: $ make make all-recursive make[1]: Entering directory '/home/dcarpenter/progs/audit/lustre/lustre' Making all in ldiskfs make[2]: Entering directory '/home/dcarpenter/progs/audit/lustre/lustre/ldiskfs' make[2]: *** No rule to make target '../ldiskfs/kernel_patches/series/ldiskfs-', needed by 'sources'. Stop. make[2]: Leaving directory '/home/dcarpenter/progs/audit/lustre/lustre/ldiskfs' autoMakefile:587: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/dcarpenter/progs/audit/lustre/lustre' autoMakefile:483: recipe for target 'all' failed make: *** [all] Error 2 On Sat, Feb 13, 2016 at 11:33:04PM -0500, green@xxxxxxxxxxxxxx wrote: > From: Oleg Drokin <green@xxxxxxxxxxxxxx> > > When we have a merged state that consists of a single state only, > e.g. because both true and false states are the same since the condition > did not affect any of them - just clone one of the original states > instead of creating a new one and assigning a current line number to it. If it's just a matter of merging the line numbers then that's simple enough... But this patch does a bunch of other stuff as well. > > This fixes an annoying problem where "xxx was used before see yyy" prints > yyy line number that dates back to previous condition, not to actual usage. Fair enough. > > Additionally when dealing with "ghost" merges this fixes some false > positives about lock imbalances for the case of The ghost merge code is dead code though. It seemed like a good idea and still does but I forgot to commit a bit of code and then in testing there was an issue and I never got around to debugging it so I just left the dead code as-is. > > if (condition) > lock(x); > some stuff; > if (some other stuff) > goto out; > > out: > if (condition) > unlock(x) > > Signed-off-by: Oleg Drokin <green@xxxxxxxxxxxxxx> > --- > > I was long annoyed by this and so using my lustre tree as benchmark > here is the difference in output before and after the patch for this file > for wrong line numbers: > http://git.whamcloud.com/fs/lustre-release.git/blob/943612ac470a1f916d44f551eee01c3d51fc9546:/lustre/lfsck/lfsck_layout.c > > -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) > +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) > > Granted, this still remains a false positive, but thta would need a more > involved fix in this particular check module. > > And here's the false positive that is now disappeared for this file: > http://git.whamcloud.com/fs/lustre-release.git/blob/943612ac470a1f916d44f551eee01c3d51fc9546:/lustre/llite/llite_lib.c > i > lustre/llite/llite_lib.c:1709 ll_setattr_raw() warn: 'mutex:&inode->i_mutex' is sometimes locked here and sometimes unlocked. The most recent Smatch is supposed to get this right. :( I don't know what's going on here. regards, dan carpenter -- 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