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]

Date:	Tue, 01 Apr 2008 12:25:44 +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>
Subject: Re: [RFC PATCH 26/26] UBIFS: include FS to compilation

Pekka Enberg wrote:
> On Tue, Apr 1, 2008 at 11:51 AM, Artem Bityutskiy <dedekind@...dex.ru> wrote:
>>  Well, its just more convenient for us. If I know the bug is somewhere in
>>  the journal, I enable the journal messages - less flooding. We may
>>  lessen the amount, but it is still handy to have some classes of
>>  prints separate.
> 
> Yeah, perhaps that's a sign that you're doing it wrong? You currently
> have 430 separate debug printks sprinkled around in UBIFS. 
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.

> The way to
> reduce that is to move as much logging as possible higher up the call
> chain and dump as much information as you can there.
Yeah, this is what the dbg_gen doing :-) But often we need messages from
lower layers, why not? I agree we should lessen the amount of prints, but
I still do not get it what is your argument against them the shiny prints
which we may compile in when we want to debug :)

> That's what
> ext2_error() does, for example. So I'm not opposed to a ubifs_error()
> or ubifs_warning() even if that's used in a controlled fashion. The
> way you do debugging checks now is totally ad hoc and IMHO not
> acceptable to the mainline kernel.
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?

> And like I said, if you need _tracing_ you might want to look at
> Ingo's ftrace or some other similar tracing infrastructure and use
> that. The upside of it is that you can basically have it enabled at
> run-time too.
This alternative is not really acceptable.  We want to have only _few_
debugging things always enabled, and have other things always compiled
out and compiled in only when hunting a problem.

> On Tue, Apr 1, 2008 at 11:51 AM, Artem Bityutskiy <dedekind@...dex.ru> wrote:
>>  Some of the checks are very heavy-weight. For example, the tree checking
>>  functions scan the whole TNC/LPT B-tree, which means they read it from
>>  flash, they check CRC, and they make sure the tree is consistent and
>>  has sane data. They are very useful when hunting bugs, but they are too
>>  slow to be always enabled.
> 
> So perhaps you could just separate those heavy-weight options and have
> all others under CONFIG_UBIFS_DEBUG?

We can if we have to. But these checks often affect the FS behavior and
sometimes make bugs go away and become unreproducible. Especially locking
problems. This is why we want to be able to enabling them separately.

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