unix_gc and file_count
From: Ravikiran G Thirumalai
Date: Mon Nov 08 2004 - 03:54:26 EST
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.
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/