linux-kernel - Re: [RFC PATCH 26/26] UBIFS: include FS to compilation

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]

Message-ID: <47F20DEE.7090105@nokia.com>
Date:	Tue, 01 Apr 2008 13:26:54 +0300
From:	Artem Bityutskiy <Artem.Bityutskiy@...ia.com>
To:	Pekka Enberg <penberg@...helsinki.fi>
CC:	Artem Bityutskiy <dedekind@...dex.ru>,
	LKML <linux-kernel@...r.kernel.org>,
	Adrian Hunter <ext-adrian.hunter@...ia.com>,
	David Woodhouse <dwmw2@...radead.org>
Subject: Re: [RFC PATCH 26/26] UBIFS: include FS to compilation

Pekka Enberg wrote:
> On Tue, Apr 1, 2008 at 12:25 PM, Artem Bityutskiy
> <Artem.Bityutskiy@...ia.com> wrote:
>> JFFS2 has the similar thing. I myself fixed bugs just by asking people
>> enabling them and sending the log. Very useful. This is why we also added
>> them to UBIFS - good JFFS2 experience.
>>
>> Why? What is wrong with this? As I said, we found it very useful in JFFS2,
>> because I has been working with JFFS2 for _long_ time. Talk to David
>> Woodhouse and ask how many times that made him fix a bug just by having
>> people send a log. Why do you want to prevent us from having this?
> 
> First and foremost, JFFS2 uses BUG_ON and doesn't invent it's own
> assert.
True. But it has checking code which may be enabled or disable.
An assert is just a special case of this. You do not say why
it hurts. For me it looks like your personal taste.

We well try to lessen the amount of asserts.

> Furthermore, the debug tracing code prints out human-readable
> text in well-thought of places.
The same is with UBIFS. We will make the amount of messages less,
and the granularity less, that it would be more "well-thought".

> But there simply is no
> comparison between JFFS2 and UBIFS debug logging code. The former is
> cleanly structured whereas yours looks to be totally ad hoc.
What exactly you think is not-structured, we'll fix this.

> But perhaps the problem will go away after you inject some sanity to
> stuff like this:
> 
> fs/ubifs/dir.c: dbg_gen("dent '%.*s' to ino %lu (nlink %d) in dir ino %lu",
> fs/ubifs/dir.c: dbg_gen("dent '%.*s' from ino %lu (nlink %d) in dir ino %lu",
> fs/ubifs/dir.c: dbg_gen("directory '%.*s', ino %lu in dir ino %lu",
> dentry->d_name.len,
> fs/ubifs/dir.c: dbg_gen("dent '%.*s', mode %#x in dir ino %lu",
> fs/ubifs/dir.c: dbg_gen("dent '%.*s' in dir ino %lu",
This means that when debugging is enabled, you'll have prints like:
UBIFS DBG (pid 28398): ubifs_create: dent 'file', mode 0x81a4 in dir ino 1
or
UBIFS DBG (pid 28398): ubifs_setattr: ino 65, ia_valid 0x70

We tried to keep messages shorter because logging takes time and long
messages make it slower to debug the code.

Anyway, we will lessen and re-view this, and make it nicer.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
--
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/