[lkml]   [2004]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subjectunix_gc and file_count
I am trying to clean up uses of file_count in 2.6 as suggested by Viro
earlier. Biggest hurdle is unix_gc. I am trying to get rid of file_count in
unix_gc. But I am not sure if I understand unix_gc very well.
I thought I'd put out questions I've been having...
Appreciate if someone can clarify.

Here goes:

unix_gc pushes a root set onto a stack. This root set is not to be garbage
collected. Root set is determined by the condition:
if (open_count > atomic_read(&unix_sk(s)->inflight))
From my understanding, for a unix socket, opencount cannot be less than
inflight, simply because unix_*_sendmsg bumps up the f_count of each struct
file of the passed fd array through scm_send. inflight is later bumped up at
unix_attach_fds for unix sockets in the fd[] payload. unix_*_recvmsg bumps
down inflight for unix sockets of the payload fd[] and later does a fput for
all fds of the payload fd array. Hence, the condition for sockets to
be GC'ed is open_count == inflight. If open_count is +'ve for a GC able socket,
it means the open_count is only because the socket is part of a fd payload
waiting to be received. Some of the sockets with open_count == inflight
may not be GC'ed if they happen to be in the receive queue as a fd payload
of a inuse unix socket (on the stack). All sockets which can be GC'ed will
be in the hash list with unix_sk(s)->gc_tree == GC_ORPHAN;
unix_gc then walks through all the unix sockets in the hashtable, and
processes sockets marked for gc (GC_ORPHAN). unix_gc frees up the skbs in the
receive queue of these unix sockets which have a fd[] payload on that skb.
Other skbs are left as is.

1. Even if gc doesn't garbage collect the fd[] payload skbs, they'll be later
freed by unix_release through __fput when the f_count for that socket goes to 0.
Isn't a GC just for fd[] payloads which will anyway be freed wasteful? I
probably am missing something here........
2. Now, other skbs are left as is, what is the need for just the fd[] payload
to be freed? Either free all skbs or free none at all no?
3. If a process does a sendmsg with SCM_RIGHTS payload and the process which
is supposed to do do recvmsg dies, will the payload fd[] f_count not hang
around for ever? Only the fds which are unix sockets will have their skbs having
fd[] load cleaned up. All struct (file)s of the payload remain....

Appreciate if someone can answer the above/point out gaps in my understanding.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:07    [W:0.048 / U:1.480 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site