Yes, it is half-decent one.
... no, actually not even that, see below.
I would like to see call numbers and entry vector diffs for
Alpha, SPARCs, MIPSes, ... as well.
> I want to ask the experts for their comment and hand over the code if the
> approach is feasible.
...
> If the code here works if the processes which have opened the file are not
> in kernel mode. And this is the part I want to have comments...
>
> A possible, but not neat solution could be be to kill that processes, uh,
> i hope you have better answers... ;-)
I do find this thing a bit surprising, I had thought we already
had this facility in the kernel ??? Perhaps not then ?
Changeing f_op field in the associated 'struct file' to point
to the revocation file operations set(s) would be the easiest way.
One way is shown at the drivers/char/tty_io.c with the way
how hungup is handled by changeing the filp->f_op field.
Another approach would be to pick the 'inode' from below the file,
and then call make_bad_inode(inode) at it.
Basically the idea is to ruin the file completely, and the only
f_op operation doable to the file is close(). All others yield
-EIO.
Also, less multiprocessing hazards at the change of f_op, when
compared to going in and calling filp_close() at all files which
get same "kill" treatment...
> If we really can get a robust implementaion in the kernel we can optimize
> it, e.g. it can finish when the usage counter is zero...
>
> Here is the code, it just walks though the task list and closes any file,
> regardless if the process is stopped in read() or running on another CPU...
...
> Bernhard
/Matti Aarnio <matti.aarnio@sonera.fi>
-
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/