linux-kernel - Re: [PATCH] jfs: Convert jfs_error to jfs_sb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1370386829.2385.95.camel@joe-AO722>
Date:	Tue, 04 Jun 2013 16:00:29 -0700
From:	Joe Perches <joe@...ches.com>
To:	Dave Kleikamp <dave.kleikamp@...cle.com>
Cc:	jfs-discussion@...ts.sourceforge.net, linux-kernel@...r.kernel.org,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH] jfs: Convert jfs_error to jfs_sb_err

(added linux-fsdevel to cc)

On Tue, 2013-06-04 at 17:25 -0500, Dave Kleikamp wrote:
> On 06/04/2013 11:28 AM, Joe Perches wrote:

> > This one takes a super_block * and emits a logging message
> > so I chose jfs_sb_err to try to describe the sb * bit.
> > 
> > I like the _err suffix is a bit better than the
> > _error suffix as it's a bit more name consistent
> > with other kernel logging mechanisms like dev_err,
> > pr_err, etc, but if you want to remain consistent
> > with other fs/,,, fine by me.
> 
> It's more than a logging mechanism. It will also make the file-system
> read-only, or panic (or do nothing else) depending on the errors= mount
> option.
> 
> > I think the other fs _error names are sub-optimal.
> 
> They perform a similar function, so I'm going to leave it as is. Even if
> the names are imperfect, it's good to have some similarities in the
> names of the functions between file systems.
> 
> > These functions are a bit overloaded too when
> > CONFIG_PRINTK is not enabled.  The format and args
> > still exist in code and I believe can not be
> > optimized away by the compiler
> > 
> > I think using macro or an in-place expansion to
> > separate the 2 parts of the reporting and then the
> > handling of of the error would be better as it
> > would allow smaller embedded use.
> 
> I can hold off on this a little while if you want to explore that idea
> as an alternate.

Nah.  Is anyone really using jfs in embedded?
I'll just rename it back to jfs_error and resubmit.

for ext[234]_error, it'd maybe make _some_ sense though.

maybe a macro like below could work

#ifdef CONFIG_PRINTK
#define ext4_error(sb, fmt, ...)		\
	ext4_error(sb, fmt, ##__VA_ARGS__)
#else
#define ext4_error(sb, fmt, ...)		\
do {						\
	if (0)					\
		printk(fmt, ##__VA_ARGS__);	\
	ext4_handle_error(sb);			\
} while (0)
#endif

This would allow the compiler to optimize away the
formats and unused args to reduce code size.

That style would even work for jfs if anyone
would really want it.

> > I submitted a patch a few years ago to do that too.
> > Dunno what happened to it,

> I might have put it off and then forgot about it. I don't remember it
> specifically.

No worries.
jfs didn't have any format/argument mismatches anyway.
I think all the other filesystems did though.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/