All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Dave Chinner <david@fromorbit.com>
Cc: Eric Sandeen <sandeen@redhat.com>, xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH, RFC] xfstests: add d_type checking to fsstress
Date: Mon, 16 Sep 2013 19:54:38 -0500	[thread overview]
Message-ID: <5237A84E.2010404@sandeen.net> (raw)
In-Reply-To: <20130916225550.GG19103@dastard>

On 9/16/13 5:55 PM, Dave Chinner wrote:
> On Mon, Sep 16, 2013 at 04:55:28PM -0500, Eric Sandeen wrote:
>> This patch adds a "-D" switch to fsstress so that every time
>> we call readdir, we stat the dentry & compare it's st_mode
>> to the d_type.
>>
>> If -D is specified only once, it ignores DT_UNKNOWN.  If specified
>> twice, it considers DT_UNKNOWN to be an error.
> 
> Hmmmm. DT_UNKNOWN is actually a valid type on disk right through to the
> userspace interface. I can't think of why we'd want to consider it
> invalid, especially as right now xfs_repair siply zeros the field
> when recreating directory entries...
> 
> Cheers,
> 
> Dave.

 no fair signing off w/ more text below ;)

>> +void test_d_type(int opno, pathname_t *f, struct dirent64 *de)
>> +{
>> +	struct stat64 sb;
>> +	char path[PATH_MAX];
>> +
>> +	snprintf(path, PATH_MAX, "%s/%s", f->path, de->d_name);
>> +
>> +	/* Don't check ./. or ./.. */
>> +	if (!strncmp(path, "./.", 3))
>> +		return;
> 
> . and .. should have the values of DT_UNKNOWN or DT_DIR. They are
> the only valid values for these entries.

Hm let me look at something, I saw something that prompted this
but now that I think about it maybe it's a bug.

>> +
>> +	if (lstat64(path, &sb)) {
>> +		printf("%d/%d: getdents - can't stat %s\n",
>> +			procid, opno, path);
>> +	} else {
>> +		int bad_d_type = 0;
>> +
>> +		switch (de->d_type) {
>> +			case DT_BLK:
>> +				if (!S_ISBLK(sb.st_mode))
>> +					bad_d_type++;
>> +				break;
>> +			case DT_CHR:
>> +				if (!S_ISCHR(sb.st_mode))
>> +					bad_d_type++;
>> +				break;
>> +			case DT_DIR:
>> +				if (!S_ISDIR(sb.st_mode))
>> +					bad_d_type++;
>> +				break;
>> +			case DT_FIFO:
>> +				if (!S_ISFIFO(sb.st_mode))
>> +					bad_d_type++;
>> +				break;
>> +			case DT_LNK:
>> +				if (!S_ISLNK(sb.st_mode))
>> +					bad_d_type++;
>> +				break;
>> +			case DT_REG:
>> +				if (!S_ISREG(sb.st_mode))
>> +					bad_d_type++;
>> +				break;
>> +			case DT_SOCK:
>> +				if (!S_ISSOCK(sb.st_mode))
>> +					bad_d_type++;
>> +				break;
>> +			case DT_UNKNOWN:
>> +				if (verify_d_type > 1)
>> +					bad_d_type++;
>> +			break;
>> +		}
> 
> And DT_WHT? That's defined on disk and in the user interface ;)

but fsstress won't create it, will it?
 
> i.e. this will not do the right thing with an unknown de->d_type.

... but we know what fsstress can possibly create, right, so testing
those created types should be safe, I'd think.

I'll give this some thought & send V2.

-Eric

> Cheers,
> 
> Dave.
> 

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

      parent reply	other threads:[~2013-09-17  0:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-16 21:55 [PATCH, RFC] xfstests: add d_type checking to fsstress Eric Sandeen
2013-09-16 22:22 ` Mark Tinguely
2013-09-16 22:55 ` Dave Chinner
2013-09-16 23:20   ` Eric Sandeen
2013-09-17  0:54   ` Eric Sandeen [this message]

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=5237A84E.2010404@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=david@fromorbit.com \
    --cc=sandeen@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.