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, 1 Apr 2008 12:15:21 +0300
From:	"Pekka Enberg" <penberg@...helsinki.fi>
To:	"Artem Bityutskiy" <dedekind@...dex.ru>
Cc:	"Artem Bityutskiy" <Artem.Bityutskiy@...ia.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"Adrian Hunter" <ext-adrian.hunter@...ia.com>
Subject: Re: [RFC PATCH 26/26] UBIFS: include FS to compilation

Hi Artem,

Pekka Enberg wrote:
> > But these don't make much sense to me. Why would you want to be able
> > to compile out printks at this granularity? Why not enable all of them
> > when CONFIG_UBIFS_FS_DEBUG is enabled?

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

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.

Pekka Enberg wrote:
> > Why would you not want to enable all of these for development kernels?

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?

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