[lkml]   [2014]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Procfs race condition bug
Alexey Dobriyan <> writes:

> [broken email]
> On Wed, Jul 9, 2014 at 3:17 PM, Alexey Dobriyan <> wrote:
>>> I originally posted this two years ago (*) but received no response.
>>> I just had a look and the problem still exists on the 3.14 kernel
>>> I am currently running.
>>> I *think* I've uncovered a race condition bug in procfs.
>>> If I attempt to open a file in /proc/net, eg "/proc/net/tcp"
>>> it works fine, but if I spawn a POSIX thread and attempt to do it
>>> from there, it *usually* fails with a "No such file or directory",
>>> but some times succeeds. If I do a system call inside the thread
>>> to look up the thread ID and then open "/proc/THREADID/net/tcp"
>>> instead, it works fine.
>>> There are more details and some example code
>>> so you can replicate the problem on a stack overflow question
>>> I asked previously here:
>>> (*)
>> Mike,
>> as was correctly notes on SO, what's happening is that original thread exits
>> before spawned thread does open().
>> ->lookup
>> proc_tgid_net_lookup
>> get_proc_task_net
>> nsproxy = NULL <== thread is dead
>> This was probably broken when /proc/net became symlink:
>> commit e9720acd728a46cb40daa52c99a979f7c4ff195c
>> Author: Pavel Emelyanov <>
>> Date: Fri Mar 7 11:08:40 2008 -0800
>> [NET]: Make /proc/net a symlink on /proc/self/net (v3)
>> So, userspace has two solutions:
>> 1) original thread doesn't exit too early
>> 2) spawned thread uses /proc/$TID
>> So,
>> we definitely broke /proc/net/tcp somewhere after netns concept was introduced.
>> But,
>> you'd have very same problem with other /proc files (anything under
>> /proc/$PID/).

Agreed it is a /proc/$TGID vs /proc/$TID issue.

In principle this is fixable by creating a /proc/current symlink that
always points to the proc directory for the current thread and then
pointing /proc/net and /proc/mounts at it.

This is one of those weird cases it so that /proc/net or /proc/mounts
resolves may actually break an existing userspace application, because
different threads can point at different values. (I very much dislike
what the linux pthread support did to /proc/self).

I tilted at that windmill once and ran out of steam. While I can write
the patch I don't have the energy to test and see if there are any
pthread programs that will break if /proc/net points to
/proc/current/net instead of /proc/self/net.

Frankly new applications should be using netlink and not /proc/net so I
personally don't think this is worth fixing for the /proc/net case. Are
there real world applications that are broken by the kernel change in
behavior? The stackoverflow discussion sounds like it was just an
investigation into weird kernel behavior.


 \ /
  Last update: 2014-07-10 07:43    [W:0.044 / U:33.344 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site