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 14:56:50 +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 1:26 PM, Artem Bityutskiy
>         ubifs_assert(PageLocked(page));
>         ubifs_assert(!PageChecked(page));
>         ubifs_assert(!PagePrivate(page));
> 
> So instead of arguing about this you really ought to look at what
> SLUB, for example, does. It's perfectly okay to have _debugging
> checks_ compiled out (stuff like verify_inode and such) but at the
> assertion level it makes no sense whatsoever!

This was more for developing. I added that to be really sure those
requirements are met. As I said, the amount of assertions will be
lessened and these ones will be deleted. There are other assertions
in the VFS calls implementation functions, which also will be deleted.

I'll look at the SLUB.

>> 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
> 
> So what? It's still an ad hoc debugging printout with no particular
> meaning whatsoever.

You still do not explain what is wrong with this. For me it means that
ubifs_setattr() was called for inode 65. And when I debugging a bug I
know what's going on.

> But this discussion is getting nowhere and I have better things to do
> than argue about this over and over again.
Fair enough. As I said, we will review debugging and lessen the amount of
it.

Thanks.

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