lkml.org 
[lkml]   [2000]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.072 / U:2.308 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site