All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shawn Bohrer <sbohrer@rgmadvisors.com>
To: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Cc: Ingo Molnar <mingo@elte.hu>, Paul Mackerras <paulus@samba.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] perf: Handle DT_UNKNOWN on filesystems that don't support d_type
Date: Sun, 21 Nov 2010 09:52:52 -0600	[thread overview]
Message-ID: <20101121155252.GA2527@BohrerMBP> (raw)
In-Reply-To: <20101121004836.GA16668@ghostprotocols.net>

On Sat, Nov 20, 2010 at 10:48:36PM -0200, Arnaldo Carvalho de Melo wrote:
> Em Sat, Nov 20, 2010 at 06:42:19PM -0600, Shawn Bohrer escreveu:
> > Some filesystems like xfs and reiserfs will return DT_UNKNOWN for the
> > d_type.  Handle this case by calling stat() to determine the type.
> 
> Thanks for the fix, just waiting for some more reviewers to chime in,
> seems odd, like readdir_r has a bug.

The readdir_r man page says the following:

       If  the  file type could not be determined, the value DT_UNKNOWN
       is returned in d_type.

       Currently, only some file  systems  (among  them:  Btrfs,  ext2,
       ext3,  and  ext4)  have  full support returning the file type in
       d_type.  All applications  must  properly  handle  a  return  of
       DT_UNKNOWN.

So it isn't a bug in readdir_r.  This also isn't the only place that
perf uses readdir/readdir_r, and doesn't handle DT_UNKNOWN. In the
other locations it looked to me like it was only reading from debugfs,
so I don't think it matters.

> Even if that is the case we'll have to cope, and doing the extra stat
> only when in "doubt" (i.e. when getting DT_UNKNOWN) seems the right
> thing to me.
> 
> - Arnaldo

  reply	other threads:[~2010-11-21 15:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-21  0:42 [PATCH] perf: Handle DT_UNKNOWN on filesystems that don't support d_type Shawn Bohrer
2010-11-21  0:48 ` Arnaldo Carvalho de Melo
2010-11-21 15:52   ` Shawn Bohrer [this message]
2010-11-21 10:01 ` Andreas Schwab
2010-11-21 15:54   ` Shawn Bohrer
2010-11-21 16:09     ` [PATCH v2] " Shawn Bohrer
2010-11-28  8:34       ` [tip:perf/core] perf trace: " tip-bot for Shawn Bohrer

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=20101121155252.GA2527@BohrerMBP \
    --to=sbohrer@rgmadvisors.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@ghostprotocols.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    /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.