Why does lsof complain about tracefs?

The answer to your question is in the file permissions:

try:

$ ls -l /sys/kernel/debug/tracing
ls: cannot access '/sys/kernel/debug/tracing': Permission denied
$ ls -l /sys/kernel
total 0
...
drwx------  31 root root    0 2016-06-15 11:06:47 debug
...

So, normal users are not allowed to access /sys/kernel/debug/tracing and there seems to be no way to ask lsof to avoid accessing it.

We could then discuss whether this is a bug or not, but the answer to your question boils down to this.

I had the same problem and this answer helped me to understand the problem a little better.

I've found out that one way to remove the annoying warning is to umount debugfs

mount | grep debugfs 
none on /sys/kernel/debug type debugfs (rw,_netdev)

sudo umount $(mount | grep debugfs | awk '{print $3}')

If you now run lsof there is no warning.

The issue is that you do not have permission to access the debugfs directory. The tracefs directory was created to allow people to mount the tracing directory directly at /sys/kernel/tracing and not require enabling debugfs. But for backward compatibility, when mounting the debugfs directory, it would automatically mount tracefs in the "tracing" directory of debugfs.

Now when you perform lsof it looks at the /proc/filesystems file as well as /proc/mounts. It sees that tracefs is mounted at /sys/kernel/debug/tracing, and thus tries to stat it. Unfortunately, because /sys/kernel/debug wont let non-root users see inside of it, you get the error message when trying to stat the directory "tracing" from within /sys/kernel/debug. If you unmount the debugfs directory, the warning will go away.