linux-kernel - Re: [PATCH 17/21] ceph: nfs re-export support

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]

Message-ID: <Pine.LNX.4.64.0906201332410.2932@cobra.newdream.net>
Date:	Sat, 20 Jun 2009 13:39:35 -0700 (PDT)
From:	Sage Weil <sage@...dream.net>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	greg@...ah.com
Subject: Re: [PATCH 17/21] ceph: nfs re-export support

On Sat, 20 Jun 2009, Stefan Richter wrote:
> Sage Weil wrote:
> > +++ b/fs/staging/ceph/export.c
> ...
> > +static struct dentry *ceph_fh_to_parent(struct super_block *sb, struct fid
> > *fid,
> > +				 int fh_len, int fh_type)
> > +{
> > +	u32 *fh = fid->raw;
> > +	u64 ino = *(u64 *)fh;
> > +	u32 hash = fh[2];
> > +
> > +	derr(10, "fh_to_parent %llx.%x\n", ino, hash);
> > +
> > +	if (fh_len < 6)
> > +		return ERR_PTR(-ESTALE);
> > +
> > +	return __fh_to_dentry(sb, (struct ceph_export_item *)fh + 1,
> > +			      fh_len/IPSZ - 1);
> > +}
> 
> fid->raw could be 32-bit aligned, couldn't it?
> 
> #include <asm/unaligned.h>
> 
> 	u64 ino = get_unaligned((u64 *)fh);

Hmm, yeah.  I've done the same thing in a bunch of other places, too, the 
big offender being decode.h, where e.g.

		v = le64_to_cpu(*(__le64 *)*(p));	\
                *(p) += sizeof(u64);                    \

should be

                v = le64_to_cpu(get_unaligned((__le64 *)*(p)));       \
                *(p) += sizeof(u64);                    \

I'll do a full audit to clean these up.

> 	derr(10, "fh_to_parent %llx.%x\n",
> 	     (unsigned long long)ino, hash);

I've been secretly hoping someone will add printk format specifiers for 
fixed size u32 and u64 so I can avoid sprinkling hundreds of (unsigned 
long long)'s throughout.  Is an explicit cast really the cleanest way to 
fix this?

Thanks!
sage
--
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/