Messages in this thread |  | | Date | Sun, 27 Aug 2000 15:26:14 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: [PATCH] thread wakeup fix for 2.4.0-test7 |
| |
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/
|  |