Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?

From: Albert Cahalan (albert_at_users.sf.net)
Date: 10/02/03

  • Next message: Dan Hollis: "problem with IDE TCQ on 2.6.0-test6" 
    To: Linus Torvalds <torvalds@osdl.org>
Date:	01 Oct 2003 19:42:26 -0400

    On Wed, 2003-10-01 at 11:11, Linus Torvalds wrote:
    > On Wed, 1 Oct 2003, Mikael Pettersson wrote:
    > >
    > > Linus' 2.6.0-test6 announcement doesn't seem to mention the
    > > fact that 2.6.0-test5-bk9 fundamentally changed the semantics
    > > of /proc/self and the /proc/<pid> name space.
    >
    > Well, that's because the semantics weren't _supposed_ to change. The new
    > semantics were meant to be a superset of the old behaviour, with just the
    > added "task" subdirectory that lists the actual threads.
    >
    > However, you're right that "/proc/self" should likely point into the
    > _thread_, and not into the task. But it's debatable. You are very likely
    > the only one who could ever care ;)

    That seems likely to break other stuff, as new-style
    threads become more common. Right now, many tools are
    unaware of new-style threads. Pointing at the tgid
    directory (POSIX PID directory) lets tools ignore threads.

    > > I don't actually disagree with the change, but it took me by
    > > surprise since neither the 2.6.0-test6 annoucement nor the
    > > diff between the t5-bk8 and t5-bk9 logs seem to mention it.
    >
    > Well, the changelog mentions "fix for hidden task problem", since the diff
    > really is mainly to _add_ threads to the /proc layout. The fact that it
    > changed /proc/self is actually a bit surprising. Albert?

    This is an interesting problem for sure. The link was
    pointing to a directory that didn't get listed, except
    that CLONE_THREAD wasn't exactly a popular feature yet.
    So it was very seldom that the distinction mattered.

    Currently, I rely on checking for /proc/self/task to
    see if threads can be examined. Like this:

    task_dir_missing = stat("/proc/self/task", &sbuf);

    That wouldn't work if /proc/self pointed at the task.

    It certainly seems to me that the intent of /proc/self is
    to point to a "process", which is a tgid in kernel terms.
    Back in the 2.4.xx days, that was a pid in kernel terms.
    Now that we have CLONE_THREAD and the tgid, a "process"
    is represented by the tgid. Pointing to the tgid matches
    what other OSes do.

    I think there is something clearly defective about having
    the /proc/self link point to a hidden directory. It could
    be pointed at /proc/42/task/58 and such I guess, but I
    think tools could break as new-style threads begin to get
    used in the real world.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Dan Hollis: "problem with IDE TCQ on 2.6.0-test6"

    Relevant Pages

    • Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
      ... and a /proc/proc (pointing to tgid) should be added. ... have top-level links for process (tgid, "proc", POSIX PID), ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: netlink nlmsg_pid supposed to be pid or tid?
      ... > Of course, it does not matter, but tgid is nicer choice from user's viewpoint. ... but I'm not sure what you mean by "it does not matter". ... receives a response to this request. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: netlink nlmsg_pid supposed to be pid or tid?
      ... I tend to agree with you here that tgid makes more sense. ... Dave, what ... send the line "unsubscribe linux-kernel" in ... More majordomo info at http://vger.kernel.org/majordomo-info.html ...
      (Linux-Kernel)