[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120913164100.GN19956@moon>
Date: Thu, 13 Sep 2012 20:41:00 +0400
From: Cyrill Gorcunov <gorcunov@...nvz.org>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: LKML <linux-kernel@...r.kernel.org>,
"H. Peter Anvin" <hpa@...or.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Pavel Emelyanov <xemul@...allels.com>
Subject: Re: [RFC] tty: Add get- ioctls to fetch tty status
On Thu, Sep 13, 2012 at 05:25:07PM +0100, Alan Cox wrote:
> On Thu, 13 Sep 2012 16:54:01 +0400
> Cyrill Gorcunov <gorcunov@...nvz.org> wrote:
>
> > On Thu, Sep 13, 2012 at 01:51:31PM +0100, Alan Cox wrote:
> > > > +static int pty_get_lock(struct tty_struct *tty, int __user *arg)
> > > > +{
> > > > + int locked = test_bit(TTY_PTY_LOCK, &tty->flags);
> > > > + if (put_user(locked, arg))
> > > > + return -EFAULT;
> > >
> > > Now explain exactly how this doesn't race with another thread chanigng
> > > the lock setting ?
> >
> > It's the same as to set/clear this bit, isn't it? Please correct me
> > if I'm wrong.
>
> So by the time you've finished the test bit and returned it to user space
> the answer may have changed?
Yes. Btw, as far as I see the same applies to lock bit on its own. One
process may lock it while another process may unlock it right after that.
> > > The other comment I have is that it might be better put these in now
> > > there are sysfs patches for the tty layer bouncing about to provide the
> > > needed infrastructure ?
> >
> > Alan, could you please point me where these patches are living, so I would
> > take a look and check them out
>
> linux-serial or check tty-next as I think Greg has now merged the test
> patch.
Ah, thanks a lot, Alan, I'll take a look!
Cyrill
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists