From: Mirsad Todorovac <mtodorovac69@gmail.com>
To: Jan Kara <jack@suse.cz>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"Gustavo A. R. Silva" <gustavoars@kernel.org>,
Kees Cook <kees@kernel.org>,
Christian Brauner <brauner@kernel.org>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Jeff Layton <jlayton@kernel.org>,
reiserfs-devel@vger.kernel.org
Subject: Re: [PROBLEM linux-next] fs/reiserfs/do_balan.c:1147:13: error: variable ‘leaf_mi’ set but not used [-Werror=unused-but-set-variable]
Date: Thu, 18 Jul 2024 00:14:24 +0200 [thread overview]
Message-ID: <83c22d71-8706-4779-8d20-6b18a75c95a5@gmail.com> (raw)
In-Reply-To: <20240717154434.jba66jupaf566tes@quack3>
On 7/17/24 17:44, Jan Kara wrote:
> On Tue 16-07-24 19:17:05, Mirsad Todorovac wrote:
>> On 7/15/24 19:28, Jan Kara wrote:
>>> Hello Mirsad!
>>>
>>> On Wed 10-07-24 20:09:27, Mirsad Todorovac wrote:
>>>> On the linux-next vanilla next-20240709 tree, I have attempted the seed KCONFIG_SEED=0xEE7AB52F
>>>> which was known from before to trigger various errors in compile and build process.
>>>>
>>>> Though this might seem as contributing to channel noise, Linux refuses to build this config,
>>>> treating warnings as errors, using this build line:
>>>>
>>>> $ time nice make W=1 -k -j 36 |& tee ../err-next-20230709-01a.log; date
>>>>
>>>> As I know that the Chief Penguin doesn't like warnings, but I am also aware that there are plenty
>>>> left, there seems to be more tedious work ahead to make the compilers happy.
>>>>
>>>> The compiler output is:
>>>>
>>>> ---------------------------------------------------------------------------------------------------------
>>>> fs/reiserfs/do_balan.c: In function ‘balance_leaf_new_nodes_paste_whole’:
>>>> fs/reiserfs/do_balan.c:1147:13: error: variable ‘leaf_mi’ set but not used [-Werror=unused-but-set-variable]
>>>> 1147 | int leaf_mi;
>>>> | ^~~~~~~
>>>
>>> Frankly, I wouldn't bother with reiserfs. The warning is there for ages,
>>> the code is going to get removed in two releases, so I guess we can live
>>> with these warnings for a few more months...
>>
>> In essence I agree with you, but for sentimental reasons I would like to
>> keep it because it is my first journaling Linux system on Knoppix 🙂
>
> As much as I understand your sentiment (I have a bit of history with that
> fs as well) the maintenance cost isn't really worth it and most fs folks
> will celebrate when it's removed. We have already announced the removal
> year and half ago and I'm fully for executing that plan at the end of this
> year.
>
>> Patch is also simple and a no-brainer, as proposed by Mr. Cook:
>>
>> -------------------------------><------------------------------------------
>> diff --git a/fs/reiserfs/do_balan.c b/fs/reiserfs/do_balan.c
>> index 5129efc6f2e6..fbe73f267853 100644
>> --- a/fs/reiserfs/do_balan.c
>> +++ b/fs/reiserfs/do_balan.c
>> @@ -1144,7 +1144,9 @@ static void balance_leaf_new_nodes_paste_whole(struct tree_balance *tb,
>> {
>> struct buffer_head *tbS0 = PATH_PLAST_BUFFER(tb->tb_path);
>> int n = B_NR_ITEMS(tbS0);
>> +#ifdef CONFIG_REISERFS_CHECK
>> int leaf_mi;
>> +#endif
>
> Well, I would not like this even for actively maintained code ;) If you
> want to silence these warnings in this dead code, then I could live with
> something like:
>
> #if defined( CONFIG_REISERFS_CHECK )
> #define RFALSE(cond, format, args...) __RASSERT(!(cond), ....)
> #else
> - #define RFALSE( cond, format, args... ) do {;} while( 0 )
> + #define RFALSE( cond, format, args... ) do { (void)cond; } while( 0 )
> #endif
Yes, one line change is much smarter than 107 line patch of mine :-)
Verified, and this line solved all the warnings:
CC fs/reiserfs/bitmap.o
CC fs/reiserfs/do_balan.o
CC fs/reiserfs/namei.o
CC fs/reiserfs/inode.o
CC fs/reiserfs/file.o
CC fs/reiserfs/dir.o
CC fs/reiserfs/fix_node.o
CC fs/reiserfs/super.o
CC fs/reiserfs/prints.o
CC fs/reiserfs/objectid.o
CC fs/reiserfs/lbalance.o
CC fs/reiserfs/ibalance.o
CC fs/reiserfs/stree.o
CC fs/reiserfs/hashes.o
CC fs/reiserfs/tail_conversion.o
CC fs/reiserfs/journal.o
CC fs/reiserfs/resize.o
CC fs/reiserfs/item_ops.o
CC fs/reiserfs/ioctl.o
CC fs/reiserfs/xattr.o
CC fs/reiserfs/lock.o
CC fs/reiserfs/procfs.o
AR fs/reiserfs/built-in.a
Just FWIW, back then in year 2000/2001 a journaling file system on my Knoppix box was a quantum
leap - it would simply replay the journal if there was a power loss before shutdown. No several
minutes of fsck.
I think your idea is great and if you wish a patch could be submitted after the merge window.
Best regards,
Mirsad
>
> Honza
next prev parent reply other threads:[~2024-07-17 22:14 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-10 18:09 Mirsad Todorovac
2024-07-10 18:17 ` Kees Cook
2024-07-10 19:14 ` Mirsad Todorovac
2024-07-15 17:28 ` Jan Kara
2024-07-16 17:17 ` Mirsad Todorovac
2024-07-17 15:44 ` Jan Kara
2024-07-17 22:14 ` Mirsad Todorovac [this message]
2024-07-18 9:39 ` Jan Kara
2024-07-19 20:51 ` Mirsad Todorovac
2024-08-02 16:31 ` Mirsad Todorovac
2024-08-05 13:04 ` Jan Kara
2024-08-05 21:24 ` Mirsad Todorovac
2024-08-06 8:25 ` Jan Kara
2024-08-11 13:34 ` Mirsad Todorovac
2024-08-11 20:52 ` Mirsad Todorovac
2024-08-27 9:24 ` Jan Kara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83c22d71-8706-4779-8d20-6b18a75c95a5@gmail.com \
--to=mtodorovac69@gmail.com \
--cc=brauner@kernel.org \
--cc=gustavoars@kernel.org \
--cc=jack@suse.cz \
--cc=jlayton@kernel.org \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=reiserfs-devel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®