Re: [PATCH] thread wakeup fix for 2.4.0-test7

From: Alexander Viro (viro@math.psu.edu)
Date: Sun Aug 27 2000 - 14:26:14 EST


On Sun, 27 Aug 2000 kuznet@ms2.inr.ac.ru wrote:

> Hello!
>
> > normal UNIX semantics. close(dup(fd)) should have _no_ effect.
>
> Grrr... No doubts!
>
> File is closed, when all the references from user disappear.

Yes? So how about
        fd2 = dup(fd1);
                                        read(fd1,...);
        close(fd1);

Is the file closed in that case? If no - you've got completely weird
semantics (having dup() changes rules for operations on original fd), if
yes - what happens with your arguments about leaks?

> I have already tried to clean this issue times in the past.
>
> File must have two refcounts: f_users and f_count.
> f_users counts references from user i.e. from file descriptor
> tables (and from a few of descriptor-less files inside kernel).
>
> fget() and fput() work on f_count.
>
> When f_users becomes zero, file is closed, but not destroyed.
> Method fops->flush() is called to shutdown it. It wakes up
> processes holding f_count on this file, particualry.

Wonderful. Now tell me what to do with SCM_RIGHTS cookies, OK? And while
you are at it, what to do with mmap()? Besides, what processes hold
->f_count on /dev/zero and how many lists poor task_struct should be on?

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



This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:19 EST