linux-ext4 - Re: [RFC] [PATCH 1/1] Nanosecond timestamps

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:	Thu, 8 Feb 2007 11:30:25 +0100
From:	Johann Lombardi <johann.lombardi@...l.net>
To:	Andreas Dilger <adilger@...sterfs.com>
Cc:	Kalpak Shah <kalpak@...sterfs.com>,
	linux-ext4 <linux-ext4@...r.kernel.org>, tytso <tytso@....edu>,
	sct <sct@...hat.com>
Subject: Re: [RFC] [PATCH 1/1] Nanosecond timestamps

On Wed, Feb 07, 2007 at 01:39:46PM -0700, Andreas Dilger wrote:
> This has been a bug in several places already, and I wonder if the
> le*_to_cpu() and cpu_to_le*() macros shouldn't do some type checking
> instead of just casting the variable to the specified type?

That would be great.

> The only problem is if casting constants it would be a bit of a pain
> to have to cast them explicitly, though we could have something like:
> 
> #define le16_to_cpu(var) (__builtin_constant(var) || !typecheck(__u16, var) ? \
> 			  __constant_cpu_to_le16(var) : __le16_to_cpu(var))

Very good idea!

> The only question is whether "typecheck" adds extra variables on the stack
> or if the compiler will always optimize them away.

I tend to think it will always be optimized by the compiler.
 
> > If the inode size is EXT3_GOOD_OLD_INODE_SIZE, sbi->s_want_extra_isize won't
> > be initialized. However, it should not be an issue because the ext3_sb_info
> > is set to zero in ext3_fill_super().
> 
> So I'm not sure I understand if you have an objection or if this is just a
> comment.

Just a useless comment :)

> sbi->s_want_extra_isize will be zero and it is not possible for
> sbi->s_inode_size < EXT3_GOOD_OLD_INODE_SIZE so this case won't be hit.

I agree.

Cheers,
Johann
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html