public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Alex Elder <aelder@sgi.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH v3, 01/16] xfsprogs: metadump: some names aren't all that special
Date: Thu, 24 Feb 2011 12:18:37 +1100	[thread overview]
Message-ID: <20110224011837.GO3166@dastard> (raw)
In-Reply-To: <201102182121.p1ILL1T8029031@stout.americas.sgi.com>

On Fri, Feb 18, 2011 at 03:21:01PM -0600, Alex Elder wrote:
> Move the check for short names out of is_special_dirent() and into
> generate_obfuscated_name().  That way the check is more directly
> associated with the algorithm that requires it.
> 
> Similarly, move the check for inode == 0, since that case has to do
> with storing extended attributes (not files) in the name table.
> 
> As a result, is_special_dirent() is really only focused on whether a
> given file is in the lost+found directory.  Rename the function to
> reflect its more specific purpose.
> 
> Signed-off-by: Alex Elder <aelder@sgi.com>
> 
> Updated:
> - The previous version did not properly skip the "lost+found"
>   directory itself; this one does.
> - Created a new definition representing the name of the orphanage
>   directory.  Encapsulate recognizing that directory into a new
>   macro, is_lost_found().
> - Removed casts that eliminate a compile warning in calls to
>   libxfs_da_hashname(); will do them separately later if needed.
> 
> ---
>  db/metadump.c |   76 +++++++++++++++++++++++++++++++++++++++-------------------
>  1 file changed, 52 insertions(+), 24 deletions(-)
> 
> Index: b/db/metadump.c
> ===================================================================
> --- a/db/metadump.c
> +++ b/db/metadump.c
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2007 Silicon Graphics, Inc.
> + * Copyright (c) 2007, 2011 SGI
>   * All Rights Reserved.
>   *
>   * This program is free software; you can redistribute it and/or
> @@ -377,40 +377,56 @@ random_filename_char(void)
>  	return c;
>  }
>  
> +/*
> + * Determine whether a name is one we shouldn't obfuscate because
> + * it's an orphan (or the "lost+found" directory itself).  Note
> + * "cur_ino" is the inode for the directory currently being
> + * processed.
> + *
> + * Returns 1 if the name should NOT be obfuscated or 0 otherwise.
> + */
> +#define	is_lost_found(mnt, dir_ino, nmlen, nm)			\
> +		((dir_ino) == (mnt)->m_sb.sb_rootino &&		\
> +			(nmlen) == ORPHANAGE_LEN &&		\
> +			!memcmp((nm), ORPHANAGE, ORPHANAGE_LEN))

Perhaps a static inline function?

> +
> +#define	ORPHANAGE	"lost+found"
> +#define	ORPHANAGE_LEN	(sizeof ORPHANAGE - 1)

sizeof works without ()? Even it is does, it is unusual to do so,
and a little ambiguous....

> +
>  static int
> -is_special_dirent(
> +in_lost_found(

Oh, that confused me for a second - in_lost_found and is_lost_found
are very similar in name, hence easily confused when scanning the
code. Not sure how better to name them, maybe you've got a better
idea, Alex?

>  	xfs_ino_t		ino,
>  	int			namelen,
>  	uchar_t			*name)
>  {
>  	static xfs_ino_t	orphanage_ino = 0;
> -	char			s[32];
> +	char			s[24];	/* 21 is enough */

Why is 21 enough?

>  	int			slen;
>  
> -	/*
> -	 * due to the XFS name hashing algorithm, we cannot obfuscate
> -	 * names with 4 chars or less.
> -	 */
> -	if (namelen <= 4)
> -		return 1;
> +	/* Record the "lost+found" inode if we haven't done so already */
>  
> -	if (ino == 0)
> +	ASSERT(ino != 0);
> +	if (!orphanage_ino && is_lost_found(mp, cur_ino, namelen, name))
> +		orphanage_ino = ino;
> +
> +	/* We don't obfuscate the "lost+found" directory itself */
> +
> +	if (ino == orphanage_ino)
> +	    	return 1;
> +
> +	/* Most files aren't in "lost+found" at all */
> +
> +	if (cur_ino != orphanage_ino)
>  		return 0;

I'm judging by this that if a directory tree is attached to
lost+found we are obfuscating anything in that subdirectory?

>  
>  	/*
> -	 * don't obfuscate lost+found nor any inodes within lost+found with
> -	 * the inode number
> +	 * Within "lost+found", we don't obfuscate any file whose
> +	 * name is the same as its inode number.  Any others are
> +	 * stray files and can be obfuscated.
>  	 */
> -	if (cur_ino == mp->m_sb.sb_rootino && namelen == 10 &&
> -			memcmp(name, "lost+found", 10) == 0) {
> -		orphanage_ino = ino;
> -		return 1;
> -	}
> -	if (cur_ino != orphanage_ino)
> -		return 0;
> +	slen = snprintf(s, sizeof s, "%llu", (unsigned long long) ino);
>  
> -	slen = sprintf(s, "%lld", (long long)ino);
> -	return (slen == namelen && memcmp(name, s, namelen) == 0);
> +	return slen == namelen && !memcmp(name, s, namelen);
>  }
>  
>  static void
> @@ -426,13 +442,25 @@ generate_obfuscated_name(
>  	xfs_dahash_t		newhash;
>  	uchar_t			newname[NAME_MAX];
>  
> -	if (is_special_dirent(ino, namelen, name))
> -		return;
> +	/*
> +	 * Our obfuscation algorithm requires at least 5-character
> +	 * names, so don't bother if the name is too short.
> +	 */
> +	if (namelen < 5)
> +	    	return;

Please make usre you include the reason for this - that this is a
property of the name hashing algorithm.

> -	hash = libxfs_da_hashname(name, namelen);
> +	/*
> +	 * We don't obfuscate "lost+found" or any orphan files
> +	 * therein.  When the name table is used for extended
> +	 * attributes, the inode number provided is 0, in which
> +	 * case we don't need to make this check.
> +	 */
> +	if (ino && in_lost_found(ino, namelen, name))
> +		return;
>  
>  	/* create a random name with the same hash value */
>  
> +	hash = libxfs_da_hashname(name, namelen);
>  	do {
>  		dup = 0;
>  		newname[0] = '/';
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
> 

-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2011-02-24  1:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-18 21:21 [PATCH v3, 01/16] xfsprogs: metadump: some names aren't all that special Alex Elder
2011-02-24  1:18 ` Dave Chinner [this message]
2011-02-24 21:50   ` Alex Elder
2011-02-25 18:13   ` [PATCH v4, " Alex Elder
2011-03-03  5:10     ` Dave Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110224011837.GO3166@dastard \
    --to=david@fromorbit.com \
    --cc=aelder@sgi.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox