On Thu, Sep 27, 2012 at 05:00:37PM +0100, Alan Cox wrote:
> > > Otherwise - TICOGPKT is specific to pty devices. Please therefore put it
> > > in the pty.c code and note that not all platforms use asm-geneic TTY
> > > ioctls so check carefully they all build.
> >
> > I put it into tty_ioctl.c
> > Otherwise - TICOGPKT is specific to pty devices. Please therefore put it
> > in the pty.c code and note that not all platforms use asm-geneic TTY
> > ioctls so check carefully they all build.
>
> I put it into tty_ioctl.c simply because TIOCPKT was there already so
> I thought it's good idea
On Thu, Sep 27, 2012 at 04:13:12PM +0100, Alan Cox wrote:
> > Well, sure inside our tool before doing checkpoint we stop all
> > tasks which are part of dumpee process tree. This unfortunatly
> > doesn't apply to these ioctl calls. Peter, any idea how to deal
> > with that?
>
> I suspect you
On Thu, Sep 27, 2012 at 04:13:12PM +0100, Alan Cox wrote:
> > Well, sure inside our tool before doing checkpoint we stop all
> > tasks which are part of dumpee process tree. This unfortunatly
> > doesn't apply to these ioctl calls. Peter, any idea how to deal
> > with that?
>
> I suspect you
> Well, sure inside our tool before doing checkpoint we stop all
> tasks which are part of dumpee process tree. This unfortunatly
> doesn't apply to these ioctl calls. Peter, any idea how to deal
> with that?
I suspect you can't deal with that. Which isn't to say you can't still
build something
On 09/27/2012 07:48 AM, Cyrill Gorcunov wrote:
On Thu, Sep 27, 2012 at 07:43:44AM -0700, H. Peter Anvin wrote:
If you can't guarantee that ALL those processes are stopped and
checkpointed/restarted, you have a huge problem.
Well, sure inside our tool before doing checkpoint we stop all
tasks
On Thu, Sep 27, 2012 at 07:43:44AM -0700, H. Peter Anvin wrote:
> >>If you can't guarantee that ALL those processes are stopped and
> >>checkpointed/restarted, you have a huge problem.
> >
> >Well, sure inside our tool before doing checkpoint we stop all
> >tasks which are part of dumpee process
On 09/27/2012 07:21 AM, Cyrill Gorcunov wrote:
On Thu, Sep 27, 2012 at 07:17:49AM -0700, H. Peter Anvin wrote:
While we easily can fetch termios settings and such, there are few bits which
are missed to expord. So this patch provides them to user-space.
What bothers me (and the same applies
On Thu, Sep 27, 2012 at 07:17:49AM -0700, H. Peter Anvin wrote:
> >While we easily can fetch termios settings and such, there are few bits which
> >are missed to expord. So this patch provides them to user-space.
> >
>
> What bothers me (and the same applies to termios) is that you have
> NO idea
On 09/27/2012 07:14 AM, Cyrill Gorcunov wrote:
On Thu, Sep 27, 2012 at 03:14:47PM +0100, Alan Cox wrote:
Alan, Greg, what's opinion? This flags fetching is the same as say fetching
of termios settings, once fetched they can be changed immediately, and it's
up to caller what to do with termios
On Thu, Sep 27, 2012 at 03:14:47PM +0100, Alan Cox wrote:
> > Alan, Greg, what's opinion? This flags fetching is the same as say fetching
> > of termios settings, once fetched they can be changed immediately, and it's
> > up to caller what to do with termios settings. No?
>
> I think you need to
> Alan, Greg, what's opinion? This flags fetching is the same as say fetching
> of termios settings, once fetched they can be changed immediately, and it's
> up to caller what to do with termios settings. No?
I think you need to explain what you expect to be doing with it, and why
it is safe in
On Mon, Sep 24, 2012 at 06:14:41PM +0400, Cyrill Gorcunov wrote:
>
> As to Alan's point on "what's the use of this if it can instantly change
> after you read the value" I guess it's the same as what we have when we
> simply set the value. Imagine we have two tasks fork'ed, first task do
> lock
On Mon, Sep 24, 2012 at 06:14:41PM +0400, Cyrill Gorcunov wrote:
As to Alan's point on what's the use of this if it can instantly change
after you read the value I guess it's the same as what we have when we
simply set the value. Imagine we have two tasks fork'ed, first task do
lock the pty
Alan, Greg, what's opinion? This flags fetching is the same as say fetching
of termios settings, once fetched they can be changed immediately, and it's
up to caller what to do with termios settings. No?
I think you need to explain what you expect to be doing with it, and why
it is safe in that
On Thu, Sep 27, 2012 at 03:14:47PM +0100, Alan Cox wrote:
Alan, Greg, what's opinion? This flags fetching is the same as say fetching
of termios settings, once fetched they can be changed immediately, and it's
up to caller what to do with termios settings. No?
I think you need to explain
On 09/27/2012 07:14 AM, Cyrill Gorcunov wrote:
On Thu, Sep 27, 2012 at 03:14:47PM +0100, Alan Cox wrote:
Alan, Greg, what's opinion? This flags fetching is the same as say fetching
of termios settings, once fetched they can be changed immediately, and it's
up to caller what to do with termios
On Thu, Sep 27, 2012 at 07:17:49AM -0700, H. Peter Anvin wrote:
While we easily can fetch termios settings and such, there are few bits which
are missed to expord. So this patch provides them to user-space.
What bothers me (and the same applies to termios) is that you have
NO idea if your
On 09/27/2012 07:21 AM, Cyrill Gorcunov wrote:
On Thu, Sep 27, 2012 at 07:17:49AM -0700, H. Peter Anvin wrote:
While we easily can fetch termios settings and such, there are few bits which
are missed to expord. So this patch provides them to user-space.
What bothers me (and the same applies
On Thu, Sep 27, 2012 at 07:43:44AM -0700, H. Peter Anvin wrote:
If you can't guarantee that ALL those processes are stopped and
checkpointed/restarted, you have a huge problem.
Well, sure inside our tool before doing checkpoint we stop all
tasks which are part of dumpee process tree. This
On 09/27/2012 07:48 AM, Cyrill Gorcunov wrote:
On Thu, Sep 27, 2012 at 07:43:44AM -0700, H. Peter Anvin wrote:
If you can't guarantee that ALL those processes are stopped and
checkpointed/restarted, you have a huge problem.
Well, sure inside our tool before doing checkpoint we stop all
tasks
Well, sure inside our tool before doing checkpoint we stop all
tasks which are part of dumpee process tree. This unfortunatly
doesn't apply to these ioctl calls. Peter, any idea how to deal
with that?
I suspect you can't deal with that. Which isn't to say you can't still
build something
On Thu, Sep 27, 2012 at 04:13:12PM +0100, Alan Cox wrote:
Well, sure inside our tool before doing checkpoint we stop all
tasks which are part of dumpee process tree. This unfortunatly
doesn't apply to these ioctl calls. Peter, any idea how to deal
with that?
I suspect you can't deal
On Thu, Sep 27, 2012 at 04:13:12PM +0100, Alan Cox wrote:
Well, sure inside our tool before doing checkpoint we stop all
tasks which are part of dumpee process tree. This unfortunatly
doesn't apply to these ioctl calls. Peter, any idea how to deal
with that?
I suspect you can't deal
Otherwise - TICOGPKT is specific to pty devices. Please therefore put it
in the pty.c code and note that not all platforms use asm-geneic TTY
ioctls so check carefully they all build.
I put it into tty_ioctl.c simply because TIOCPKT was there already so
I thought it's good idea to keep
On Thu, Sep 27, 2012 at 05:00:37PM +0100, Alan Cox wrote:
Otherwise - TICOGPKT is specific to pty devices. Please therefore put it
in the pty.c code and note that not all platforms use asm-geneic TTY
ioctls so check carefully they all build.
I put it into tty_ioctl.c simply because
On Sun, Sep 23, 2012 at 07:46:24AM -0700, H. Peter Anvin wrote:
> Cyrill Gorcunov wrote:
>
> >On Sat, Sep 22, 2012 at 06:09:53PM -0700, Greg Kroah-Hartman wrote:
> >> On Sun, Sep 23, 2012 at 01:52:32AM +0400, Cyrill Gorcunov wrote:
> >> > On Sun, Sep 23, 2012 at 12:11:44AM +0400, Cyrill Gorcunov
On Sun, Sep 23, 2012 at 07:46:24AM -0700, H. Peter Anvin wrote:
Cyrill Gorcunov gorcu...@openvz.org wrote:
On Sat, Sep 22, 2012 at 06:09:53PM -0700, Greg Kroah-Hartman wrote:
On Sun, Sep 23, 2012 at 01:52:32AM +0400, Cyrill Gorcunov wrote:
On Sun, Sep 23, 2012 at 12:11:44AM +0400, Cyrill
On Sun, Sep 23, 2012 at 07:44:54AM -0700, H. Peter Anvin wrote:
>
> Funny... I gave you that feedback the last go around.
I'm sorry, Peter, I guess I simply missed it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
On Sun, Sep 23, 2012 at 07:46:24AM -0700, H. Peter Anvin wrote:
> >changed right after that operation). Maybe I should put everything to
> >procfs, or stick back with ioctl calls?
>
> The problem as I see it is that you don't know if your process is
> the lock holder.
Wait, Peter, this lock is
Cyrill Gorcunov wrote:
>On Sat, Sep 22, 2012 at 06:09:53PM -0700, Greg Kroah-Hartman wrote:
>> On Sun, Sep 23, 2012 at 01:52:32AM +0400, Cyrill Gorcunov wrote:
>> > On Sun, Sep 23, 2012 at 12:11:44AM +0400, Cyrill Gorcunov wrote:
>> > >
>> > > > Sysfs is one value per file, you have three
Cyrill Gorcunov wrote:
>On Sat, Sep 22, 2012 at 06:43:37PM -0700, Eric W. Biederman wrote:
>>
>> I don't know where this conversation comes from but putting ptys in
>> sysfs in combination with the newinstance mount option is completely
>> broken unless the device name and device number
On Sat, Sep 22, 2012 at 06:43:37PM -0700, Eric W. Biederman wrote:
>
> I don't know where this conversation comes from but putting ptys in
> sysfs in combination with the newinstance mount option is completely
> broken unless the device name and device number duplication is handled,
> which I
On Sat, Sep 22, 2012 at 06:09:53PM -0700, Greg Kroah-Hartman wrote:
> On Sun, Sep 23, 2012 at 01:52:32AM +0400, Cyrill Gorcunov wrote:
> > On Sun, Sep 23, 2012 at 12:11:44AM +0400, Cyrill Gorcunov wrote:
> > >
> > > > Sysfs is one value per file, you have three values here, please make 3
> > > >
On Sat, Sep 22, 2012 at 06:09:53PM -0700, Greg Kroah-Hartman wrote:
On Sun, Sep 23, 2012 at 01:52:32AM +0400, Cyrill Gorcunov wrote:
On Sun, Sep 23, 2012 at 12:11:44AM +0400, Cyrill Gorcunov wrote:
Sysfs is one value per file, you have three values here, please make 3
files.
On Sat, Sep 22, 2012 at 06:43:37PM -0700, Eric W. Biederman wrote:
I don't know where this conversation comes from but putting ptys in
sysfs in combination with the newinstance mount option is completely
broken unless the device name and device number duplication is handled,
which I don't
Cyrill Gorcunov gorcu...@openvz.org wrote:
On Sat, Sep 22, 2012 at 06:43:37PM -0700, Eric W. Biederman wrote:
I don't know where this conversation comes from but putting ptys in
sysfs in combination with the newinstance mount option is completely
broken unless the device name and device
Cyrill Gorcunov gorcu...@openvz.org wrote:
On Sat, Sep 22, 2012 at 06:09:53PM -0700, Greg Kroah-Hartman wrote:
On Sun, Sep 23, 2012 at 01:52:32AM +0400, Cyrill Gorcunov wrote:
On Sun, Sep 23, 2012 at 12:11:44AM +0400, Cyrill Gorcunov wrote:
Sysfs is one value per file, you have three
On Sun, Sep 23, 2012 at 07:46:24AM -0700, H. Peter Anvin wrote:
changed right after that operation). Maybe I should put everything to
procfs, or stick back with ioctl calls?
The problem as I see it is that you don't know if your process is
the lock holder.
Wait, Peter, this lock is set via
On Sun, Sep 23, 2012 at 07:44:54AM -0700, H. Peter Anvin wrote:
Funny... I gave you that feedback the last go around.
I'm sorry, Peter, I guess I simply missed it.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
I don't know where this conversation comes from but putting ptys in
sysfs in combination with the newinstance mount option is completely
broken unless the device name and device number duplication is handled,
which I don't see here.
Cyrill Gorcunov writes:
>
> Guys, you mean something like
On Sun, Sep 23, 2012 at 01:52:32AM +0400, Cyrill Gorcunov wrote:
> On Sun, Sep 23, 2012 at 12:11:44AM +0400, Cyrill Gorcunov wrote:
> >
> > > Sysfs is one value per file, you have three values here, please make 3
> > > files.
> > >
> > > And document them in Documentation/ABI/.
> >
> > Hmm, sure
> > Guys, you mean something like below? Look, I must admit I'm not really
> > sure if I've done all locking right, and there is no need for additional
> > kref counting on tty_struct. Could you please check if it looks more-less
> > sane (I've tested it but still...)
This still doesn't answer
On Sun, Sep 23, 2012 at 12:11:44AM +0400, Cyrill Gorcunov wrote:
>
> > Sysfs is one value per file, you have three values here, please make 3
> > files.
> >
> > And document them in Documentation/ABI/.
>
> Hmm, sure Greg, I'll update. Thanks!
Something like below I suppose? Look, if there will
On Sat, Sep 22, 2012 at 01:07:31PM -0700, Greg Kroah-Hartman wrote:
> > drivers/tty/pty.c | 45 -
> > 1 file changed, 44 insertions(+), 1 deletion(-)
> >
> > Index: tty.git/drivers/tty/pty.c
> >
On Sat, Sep 22, 2012 at 10:06:39PM +0400, Cyrill Gorcunov wrote:
> On Thu, Sep 13, 2012 at 05:25:07PM +0100, Alan Cox wrote:
> > On Thu, 13 Sep 2012 16:54:01 +0400
> > Cyrill Gorcunov wrote:
> >
> > > On Thu, Sep 13, 2012 at 01:51:31PM +0100, Alan Cox wrote:
> > > > > +static int
On Thu, Sep 13, 2012 at 05:25:07PM +0100, Alan Cox wrote:
> On Thu, 13 Sep 2012 16:54:01 +0400
> Cyrill Gorcunov 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
On Thu, Sep 13, 2012 at 05:25:07PM +0100, Alan Cox wrote:
On Thu, 13 Sep 2012 16:54:01 +0400
Cyrill Gorcunov gorcu...@openvz.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
On Sat, Sep 22, 2012 at 10:06:39PM +0400, Cyrill Gorcunov wrote:
On Thu, Sep 13, 2012 at 05:25:07PM +0100, Alan Cox wrote:
On Thu, 13 Sep 2012 16:54:01 +0400
Cyrill Gorcunov gorcu...@openvz.org wrote:
On Thu, Sep 13, 2012 at 01:51:31PM +0100, Alan Cox wrote:
+static int
On Sat, Sep 22, 2012 at 01:07:31PM -0700, Greg Kroah-Hartman wrote:
drivers/tty/pty.c | 45 -
1 file changed, 44 insertions(+), 1 deletion(-)
Index: tty.git/drivers/tty/pty.c
On Sun, Sep 23, 2012 at 12:11:44AM +0400, Cyrill Gorcunov wrote:
Sysfs is one value per file, you have three values here, please make 3
files.
And document them in Documentation/ABI/.
Hmm, sure Greg, I'll update. Thanks!
Something like below I suppose? Look, if there will be no
Guys, you mean something like below? Look, I must admit I'm not really
sure if I've done all locking right, and there is no need for additional
kref counting on tty_struct. Could you please check if it looks more-less
sane (I've tested it but still...)
This still doesn't answer the
On Sun, Sep 23, 2012 at 01:52:32AM +0400, Cyrill Gorcunov wrote:
On Sun, Sep 23, 2012 at 12:11:44AM +0400, Cyrill Gorcunov wrote:
Sysfs is one value per file, you have three values here, please make 3
files.
And document them in Documentation/ABI/.
Hmm, sure Greg, I'll update.
I don't know where this conversation comes from but putting ptys in
sysfs in combination with the newinstance mount option is completely
broken unless the device name and device number duplication is handled,
which I don't see here.
Cyrill Gorcunov gorcu...@openvz.org writes:
Guys, you mean
On Thu, Sep 13, 2012 at 05:25:07PM +0100, Alan Cox wrote:
> On Thu, 13 Sep 2012 16:54:01 +0400
> Cyrill Gorcunov 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
On Thu, 13 Sep 2012 16:54:01 +0400
Cyrill Gorcunov 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, >flags);
> > > + if (put_user(locked, arg))
> > > +
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, >flags);
> > + if (put_user(locked, arg))
> > + return -EFAULT;
>
> Now explain exactly how this doesn't
> +static int pty_get_lock(struct tty_struct *tty, int __user *arg)
> +{
> + int locked = test_bit(TTY_PTY_LOCK, >flags);
> + if (put_user(locked, arg))
> + return -EFAULT;
Now explain exactly how this doesn't race with another thread chanigng
the lock setting ?
The other
On Thu, Sep 13, 2012 at 01:46:53PM +0200, Jiri Slaby wrote:
> On 09/13/2012 11:56 AM, Cyrill Gorcunov wrote:
> > For checkpoint/restore we need to know if tty has
> > exclusive or packet mode set, as well as if pty
> > is currently locked. Just to be able to restore
> > this characteristics.
> >
On 09/13/2012 11:56 AM, Cyrill Gorcunov wrote:
> For checkpoint/restore we need to know if tty has
> exclusive or packet mode set, as well as if pty
> is currently locked. Just to be able to restore
> this characteristics.
>
> For this sake the following ioctl codes are introduced
>
> - TIOGPKT
For checkpoint/restore we need to know if tty has
exclusive or packet mode set, as well as if pty
is currently locked. Just to be able to restore
this characteristics.
For this sake the following ioctl codes are introduced
- TIOGPKT to get packet mode state
- TIOGPTLCK to get Pty locked state
For checkpoint/restore we need to know if tty has
exclusive or packet mode set, as well as if pty
is currently locked. Just to be able to restore
this characteristics.
For this sake the following ioctl codes are introduced
- TIOGPKT to get packet mode state
- TIOGPTLCK to get Pty locked state
On 09/13/2012 11:56 AM, Cyrill Gorcunov wrote:
For checkpoint/restore we need to know if tty has
exclusive or packet mode set, as well as if pty
is currently locked. Just to be able to restore
this characteristics.
For this sake the following ioctl codes are introduced
- TIOGPKT to get
On Thu, Sep 13, 2012 at 01:46:53PM +0200, Jiri Slaby wrote:
On 09/13/2012 11:56 AM, Cyrill Gorcunov wrote:
For checkpoint/restore we need to know if tty has
exclusive or packet mode set, as well as if pty
is currently locked. Just to be able to restore
this characteristics.
For this
+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 ?
The other
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
On Thu, 13 Sep 2012 16:54:01 +0400
Cyrill Gorcunov gorcu...@openvz.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))
On Thu, Sep 13, 2012 at 05:25:07PM +0100, Alan Cox wrote:
On Thu, 13 Sep 2012 16:54:01 +0400
Cyrill Gorcunov gorcu...@openvz.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
68 matches
Mail list logo
