Re: [igt-dev] [PATCH i-g-t v3] i915/perf: Find the associated perf-type for a particular device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Quoting Tvrtko Ursulin (2020-01-14 10:09:15)
> 
> On 10/01/2020 11:53, Chris Wilson wrote:
> > -uint64_t i915_type_id(void)
> > +static char *bus_address(int i915, char *path, int pathlen)
> > +{
> > +     struct stat st;
> > +     int len = -1;
> > +     int dir;
> > +     char *s;
> > +
> > +     if (fstat(i915, &st) || !S_ISCHR(st.st_mode))
> > +             return NULL;
> > +
> > +     snprintf(path, pathlen, "/sys/dev/char/%d:%d",
> > +              major(st.st_rdev), minor(st.st_rdev));
> > +
> > +     dir = open(path, O_RDONLY);
> > +     if (dir != -1) {
> > +             len = readlinkat(dir, "device", path, pathlen - 1);
> > +             close(dir);
> > +     }
> > +     if (len < 0)
> > +             return NULL;
> > +
> > +     path[len] = '\0';
> 
> In the realm of hypothetical but an assert that no truncation occurred 
> would be good.
> 
> if (len == pathlen - 1)
>         return NULL;
> 
> ?
> 
> Although it is not clear to me from man readlinkat how do we distinguish 
> between truncation and exact fit.
> 
> Or you were counting on failure at a later step if truncation occurred?

I did not expect a partial match to ever succeed. We at least know for
the moment the names are fixed.

> Maybe try stat(2) in this wrapper to be sure function returns a valid path?

That would have the same danger of a partial match.

I think the foolproof solution here is having pmu_name in
/sys/class/drm/cardN/pmu_name. (Or rather
/sys/dev/char/%d:%d/device/pnu_name. :)
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx



[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux