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] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 04 Jun 2013 17:25:40 -0500
From:	Dave Kleikamp <dave.kleikamp@...cle.com>
To:	Joe Perches <joe@...ches.com>
CC:	jfs-discussion@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] jfs: Convert jfs_error to jfs_sb_err

On 06/04/2013 11:28 AM, Joe Perches wrote:
> On Tue, 2013-06-04 at 11:00 -0500, Dave Kleikamp wrote:
>> I generally like this cleanup except for one thing.
>>
>> On 06/04/2013 12:22 AM, Joe Perches wrote:
>>> Use a more current logging style.
>>>
>>> Rename function jfs_error to jfs_sb_err.
>>
>> Why the rename? If you're going to rename it, the new name should be
>> more descriptive, such as jfs_report_and_handle_error(), but I don't
>> like that because it's too long. jfs_error() is similiar to ext4_error()
>> or btrfs_error(). I don't understand the name change.
> 
> Pick a name.  I don't much care what it is really.

I'm just going to stick with jfs_error, since I'm not convinced changing
the name has any benefit.

> 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.

>>> Add __printf format and argument verification.
>>
>> good
> 
> 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.

> 
>>> Remove embedded function names from formats.
>>> Add %pf, __builtin_return_address(0) to jfs_sb_err.
>>
>> I like this.
> 
> It also reduces stack needs a bit by removing that
> 256 byte temp buffer.

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ