Hi Peter,
that happened that in a sake of restoring ptys after checkpoint
we need to create them with predefined indices, as they were at
moment of dumping. So we have two options -- 1) Open terminals
in sequence until needed index reached 2) Use some other way to
say the kernel that some index is preferred.
So I thought, would it be acceptible to provide such hint via
sysctl, as in patch below (note I've not even compiled it yet,
but would like to know your opinion early).
(Maybe even make it one shot, thus once ida_get_new_above called
the pty_next reset to zero).
---
fs/devpts/inode.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
Index: linux-2.6.git/fs/devpts/inode.c
===================================================================
--- linux-2.6.git.orig/fs/devpts/inode.c
+++ linux-2.6.git/fs/devpts/inode.c
@@ -45,6 +45,7 @@ static int pty_reserve = NR_UNIX98_PTY_R
static int pty_limit_min;
static int pty_limit_max = INT_MAX;
static int pty_count;
+static int pty_next;
static struct ctl_table pty_table[] = {
{
@@ -69,6 +70,12 @@ static struct ctl_table pty_table[] = {
.mode = 0444,
.data = &pty_count,
.proc_handler = proc_dointvec,
+ }, {
+ .procname = "next",
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .data = &pty_next,
+ .proc_handler = proc_dointvec,
},
{}
};
@@ -516,7 +523,7 @@ retry:
return -ENOSPC;
}
- ida_ret = ida_get_new(&fsi->allocated_ptys, &index);
+ ida_ret = ida_get_new_above(&fsi->allocated_ptys, pty_next, &index);
if (ida_ret < 0) {
mutex_unlock(&allocated_ptys_lock);
if (ida_ret == -EAGAIN)
On 08/15/2012 08:25 AM, Cyrill Gorcunov wrote:
> Hi Peter,
>
> that happened that in a sake of restoring ptys after checkpoint
> we need to create them with predefined indices, as they were at
> moment of dumping. So we have two options -- 1) Open terminals
> in sequence until needed index reached 2) Use some other way to
> say the kernel that some index is preferred.
>
> So I thought, would it be acceptible to provide such hint via
> sysctl, as in patch below (note I've not even compiled it yet,
> but would like to know your opinion early).
>
> (Maybe even make it one shot, thus once ida_get_new_above called
> the pty_next reset to zero).
>
Pardon me while I vomit... an interaction between sysctl and open? Talk
about a race condition from hell. It is stateful, and not connected to
the filesystem instance that it is supposed to be affecting. So no,
please don't. I understand your objective but it really needs to be
something attached to the pts filesystem instance in question.
-hpa
On Wed, Aug 15, 2012 at 09:16:10AM -0700, H. Peter Anvin wrote:
> On 08/15/2012 08:25 AM, Cyrill Gorcunov wrote:
> > Hi Peter,
> >
> > that happened that in a sake of restoring ptys after checkpoint
> > we need to create them with predefined indices, as they were at
> > moment of dumping. So we have two options -- 1) Open terminals
> > in sequence until needed index reached 2) Use some other way to
> > say the kernel that some index is preferred.
> >
> > So I thought, would it be acceptible to provide such hint via
> > sysctl, as in patch below (note I've not even compiled it yet,
> > but would like to know your opinion early).
> >
> > (Maybe even make it one shot, thus once ida_get_new_above called
> > the pty_next reset to zero).
> >
>
> Pardon me while I vomit... an interaction between sysctl and open? Talk
> about a race condition from hell. It is stateful, and not connected to
> the filesystem instance that it is supposed to be affecting. So no,
> please don't. I understand your objective but it really needs to be
> something attached to the pts filesystem instance in question.
Sure, i'll think on finding some other way to provide such hint to the
kernel.
Cyrill