On Fri, 23 Jun 2000, Tigran Aivazian wrote:
> On Fri, 23 Jun 2000, Tim Waugh wrote:
>
> > On Fri, Jun 23, 2000 at 05:18:03PM +0100, Tigran Aivazian wrote:
> >
> > > How?
> >
> > ptrace
> >
>
> in the world where one can single-step a process and replace any
> instruction with any other one could say "everything is possible in
> userspace". So I still see no valid way to do it other than the same thing
> that causes some people to say that it is possible to replace system calls
> in userspace (there is even a very interesting program with a very long
> name that does it - forgot the name, that fiddles with ptrace "beyond
> the normal human's anticipation of what ptrace(2) is for"). Existence of
> programs that do the impossible is not a proof that that "impossible" is
> now possible :)
>
> So, I still think that at the moment there is NO (neither kernel nor
> userspace) way to close a given process' file descriptor. To do that one
> needs to (at least, there are lots of other issues!) enhance the lock
> subsystem to get rid of all references to 'current' context (used for
> deadlock avoidance detection, presumably). The only thing that *can* be
> done now is to switch a reference to a file to another file from a
> specially written filesystem for this very purpose. This will leak a
> little memory until the POSIX locks are fixed but is the best one can do
> for now.
>
Ok, I admit that for the very narrow task of "close a given fd of a given
process" your approach of forcing a victim process to execute (in its own
context, that is nice for locks!) a piece of code is perfectly valid
although is very sensitive to ptrace(2) working correctly.
However, I was against it because I thought of a more global task
"forcibly umount a given filesystem" for which your ptrace approach would
be just as useless as "fuser -k" or even "in-kernel fuser -k" i.e. after
you closed some, the process will open a few more.
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:26 EST