Linux-kernel mailing list archive 1997-49,: Re: [PATCH-V3!][2.1.71] BSD revoke() syscall

# Re: [PATCH-V3!][2.1.71] BSD revoke() syscall

Matthew Kirkwood (weejock@ferret.lmh.ox.ac.uk)
Thu, 11 Dec 1997 02:38:05 +0000 (GMT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: A.N.Kuznetsov: "Re: Packet Schedulers in 2.1.71, will they become active?"
- Previous message: Bjarne Lorftesonne: "Re: copy-bit macro"

On Wed, 10 Dec 1997, Theodore Y. Ts'o wrote:

> Now, however, when I revoke() a tty, I get the famous old "tty->count !=
> #fd's".
>
> Oh, I see. We need the following change in tty_io.c as well, which
> should be safe (although I haven't tested it yet):
>
> (pseudo-patch follows)
>
> tty_io.c, arround line 1127:
>
> + filp->private_data = 0;
> /* check whether both sides are closing ... */
> if (!tty_closing || (o_tty && !o_tty_closing))
> return;
> - filp->private_data = 0;

OK. Have done that, and it doesn't _seem_ to kill anything.
(That is - I can revoke ttys just fine now.)

I do have vague inklings that there might be a leak somewhere
between these things:

static int revoked_release(struct inode * inode, struct file * filp)
{
filp->f_op = NULL;
return 0;
}

static void do_revoke(struct inode * inode, struct file * filp)
{
/* Close the file */
if(filp->f_op->release)
(*filp->f_op->release)(inode, filp);

/* The file_ops to do what we want... */
filp->f_op = &revokedf_ops;
}

Are they likely to lose things?

Matthew.

- Next message: A.N.Kuznetsov: "Re: Packet Schedulers in 2.1.71, will they become active?"
- Previous message: Bjarne Lorftesonne: "Re: copy-bit macro"