linux-kernel - Re: [PATCH] UDF: check for allocated memory for inode data

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:	Wed, 16 May 2007 19:38:52 +0200
From:	Jan Kara <jack@...e.cz>
To:	Cyrill Gorcunov <gorcunov@...il.com>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Ben Fennema <bfennema@...con.csc.calpoly.edu>
Subject: Re: [PATCH] UDF: check for allocated memory for inode data

> [Christoph Hellwig - Sun, May 13, 2007 at 10:01:26PM +0100]
> | On Fri, May 11, 2007 at 03:09:20PM +0400, Cyrill Gorcunov wrote:
> | > | > | And please get rid of the UDF_I_* macro for everything you touch, just
> | > | > | put a
> | > | > | 
> | > | > | 	struct udf_inode_info *uip = UDF_I(inode);
> | > | > | 
> | > | > | at the beginning of the function and use the fields directly.
> | > | > | 
> | > | > 
> | > | > Actually to properly remove UDF_I* and UDF_SB_* macroses in the
> | > | > whole UDF subsystem - is _lot_ of work. I'm going to make it but
> | > | > not now (too busy).
> | > | 
> | > | Doing it completely is a lot of work, yes.  I was more thinking of
> | > | converting a piece of code once you do major changes.  But if you
> | > | want to convert all the code as a separate patch I'm more than happy
> | > | aswell.
> | > | 
> | > 
> | > Christoph, my only argue against getting rid of UDF_I_* macro in
> | > my patch is UDF coding style, I don't want to damage it. I think
> | > we may leave it as is (including my patch). So just review the patch
> | > I sent (second version) and Ack it then so Andrew could include it
> | > into mm tree. Meantime I'm rewritting the whole UDF subsystem to
> | > get rid of that macroses (it will be a long way ;)
> | 
> | The UDF style is horrible and very unlike other kernel code.  Given
> | that udf has been pretty much unmtained for a while there should be
> | nothing in the way of fixing it.
> | 
> | Anyway, the patch is technically correct so you'll get my ACK (not
> | that you should need it).
> | 
> 
> you know I've read UDF sources. As I understand all UDF_I_ macroses
> could be converted without breaking UDF state but... as you exactly
> mentoined it's style is horrible and I'm thinking about rewritting the
> whole UDF system. Unfortunelly I'm not _mature_ kernel developer (I'm kernel
> newbie) and it could take a long time for this (I think something like
> ~ 3 month or more ;). Actually I'm ready to spend my free time for
> this. So how do you think could it be reasonable?
  I've spent some time hunting bugs in UDF recently so I'll warn you a
bit :). Definitely rewriting that ... code would be a good thing to do
(reading that code I had urges to do it several times). The hard thing
is that there is no reasonable spec you could use - there are two
documents which define how UDF should look like but they are really hard
to read (they have like hundred pages each and one does not make sence
without the other). And reading the code and learning how the filesystem is
supposed to work isn't too helpful either. Just a friendly warning ;)

								Honza
-- 
Jan Kara <jack@...e.cz>
SuSE CR Labs
-
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/