On Thu, May 11, 2023 at 12:47:16PM -0500, Linus Torvalds wrote: > On Thu, May 11, 2023 at 11:50 AM Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > > > > ...and which version is that? The build robot report just says ia64 > > without specifying any details about what compiler was running, etc: > > Actually, you should find it if you follow the links to the config. The link in the 9 May report: https://lore.kernel.org/oe-kbuild-all/202304140707.CoH337Ux-lkp@xxxxxxxxx/ goes to an old report from 14 April involving gcc 12.1 on powerpc and doesn't mention xfs at all. > We have the compiler version saved in the config file partly exactly > for reasons like that. > > HOWEVER. > > If it's *this* report: > > > https://lore.kernel.org/linux-xfs/20230510165934.5Zgh4%25lkp@xxxxxxxxx/T/#u > > then don't even worry about it. > > That's not even a compiler warning - that "ignoring unreachable code" > is from smatch. > > So if *that* single line of > > fs/xfs/scrub/fscounters.c:459 xchk_fscounters() warn: ignoring > unreachable code. > > was all this was about, then there are no worries with that pull request. > > Those extra warnings (some of them compiler warnings enabled with W=2 > for extra warnings, some from smatch) are not a cause for worry. They > are janitorial. > > I thought you had an actual failed build report due to some warning. > Those we *do* need to fix, exactly because they will affect other > peoples ability to do basic sanity testing. AFAICT there aren't any actual build failures, just the smatch warning. > So if you can confirm that it was just that one smatch warning line > and nothing else, then I'll happily do that pull. Yes, it is the smatch warning. Sprinkling #if 0's everywhere makes the smatch warning go away, but the "shut up the warnings" fix isn't necessarily better: diff --git a/fs/xfs/scrub/fscounters.c b/fs/xfs/scrub/fscounters.c index e382a35e98d8..09101ba0aae3 100644 --- a/fs/xfs/scrub/fscounters.c +++ b/fs/xfs/scrub/fscounters.c @@ -165,6 +165,7 @@ xchk_setup_fscounters( * xchk_*_process_error. */ +#if 0 /* Count free space btree blocks manually for pre-lazysbcount filesystems. */ static int xchk_fscount_btreeblks( @@ -349,6 +350,7 @@ xchk_fscount_count_frextents( return 0; } #endif /* CONFIG_XFS_RT */ +#endif /* 0 */ /* * Part 2: Comparing filesystem summary counters. All we have to do here is @@ -422,7 +424,6 @@ xchk_fscounters( struct xfs_mount *mp = sc->mp; struct xchk_fscounters *fsc = sc->buf; int64_t icount, ifree, fdblocks, frextents; - int error; /* Snapshot the percpu counters. */ icount = percpu_counter_sum(&mp->m_icount); @@ -449,9 +450,11 @@ xchk_fscounters( /* * XXX: We can't quiesce percpu counter updates, so exit early. * This can be re-enabled when we gain exclusive freeze functionality. + * Use preprocessor crud to avoid warnings about unreachable code + * since we'd rather leave the git history of the (now unused) code + * intact until we can fix the problem. */ - return 0; - +#if 0 /* * If ifree exceeds icount by more than the minimum variance then * something's probably wrong with the counters. @@ -488,5 +491,6 @@ xchk_fscounters( fsc->frextents)) xchk_set_corrupt(sc); +#endif return 0; } --D > Linus
