[PATCH v2] TTY: pty, fix pty counting in "/proc/sys/kernel/pty/nr"

[PATCH v2] TTY: pty, fix pty counting in "/proc/sys/kernel/pty/nr"

[Ilya Zykov]

Regression for commit: 24d406a6bf736f7aebdc8fa0f0ec86e0890c6d24
Commit: 24d406a6b accepted in Linux 3.1.
Disscussed on linux-kernel@vger.kernel.org "subject: [PATCH] TTY: pty, fix pty counting"
and not accepted.
Although, I think it's clear.

diff -uprN -X ../../dontdiff a/drivers/tty/pty.c b/drivers/tty/pty.c
--- a/drivers/tty/pty.c	2011-05-19 08:06:34.000000000 +0400
+++ b/drivers/tty/pty.c	2011-10-24 23:59:23.000000000 +0400
@@ -36,13 +36,15 @@
 static struct tty_driver *ptm_driver;
 static struct tty_driver *pts_driver;
 #endif
+static int pty_count;
 
 static void pty_close(struct tty_struct *tty, struct file *filp)
 {
 	BUG_ON(!tty);
-	if (tty->driver->subtype == PTY_TYPE_MASTER)
+	if (tty->driver->subtype == PTY_TYPE_MASTER) {
 		WARN_ON(tty->count > 1);
-	else {
+		pty_count--;
+	} else {
 		if (tty->count > 2)
 			return;
 	}
@@ -446,7 +448,6 @@ static inline void legacy_pty_init(void)
 int pty_limit = NR_UNIX98_PTY_DEFAULT;
 static int pty_limit_min;
 static int pty_limit_max = NR_UNIX98_PTY_MAX;
-static int pty_count;
 
 static struct cdev ptmx_cdev;
 
@@ -599,15 +600,9 @@ free_mem_out:
 	return -ENOMEM;
 }
 
-static void pty_unix98_remove(struct tty_driver *driver, struct tty_struct *tty)
-{
-	pty_count--;
-}
-
 static const struct tty_operations ptm_unix98_ops = {
 	.lookup = ptm_unix98_lookup,
 	.install = pty_unix98_install,
-	.remove = pty_unix98_remove,
 	.open = pty_open,
 	.close = pty_close,
 	.write = pty_write,
@@ -624,7 +619,6 @@ static const struct tty_operations ptm_u
 static const struct tty_operations pty_unix98_ops = {
 	.lookup = pts_unix98_lookup,
 	.install = pty_unix98_install,
-	.remove = pty_unix98_remove,
 	.open = pty_open,
 	.close = pty_close,
 	.write = pty_write,
Signed-off-by: Ilya Zykov <ilya@ilyx.ru>

Re: [PATCH v2] TTY: pty, fix pty counting in "/proc/sys/kernel/pty/nr"

[Greg KH]

On Thu, Oct 27, 2011 at 01:48:35PM +0400, Ilya Zykov wrote:
> Regression for commit: 24d406a6bf736f7aebdc8fa0f0ec86e0890c6d24
> Commit: 24d406a6b accepted in Linux 3.1.
> Disscussed on linux-kernel@vger.kernel.org "subject: [PATCH] TTY: pty, fix pty counting"
> and not accepted.
> Although, I think it's clear.

Ilya, is there some reason you are ignoring the tty maintainer and
sending these to Linus directly?  These patches need to be tested in
linux-next, so at the earliest, they can be merged into Linus's tree for
3.3, they are NOT 3.2 material, especially given that they are not even
accepted by the current tty developers.

So please work with us, and don't try to circumvent the existing
process, it is not the way we work here.

Especially as this specific patch was already rejected, for very good
reasons, why are you ignoring those reasons?

thanks,

greg k-h

Re: [PATCH v2] TTY: pty, fix pty counting in "/proc/sys/kernel/pty/nr"

[Ilya Zykov]

Greg KH wrote:

> On Thu, Oct 27, 2011 at 01:48:35PM +0400, Ilya Zykov wrote:
>> Regression for commit: 24d406a6bf736f7aebdc8fa0f0ec86e0890c6d24
>> Commit: 24d406a6b accepted in Linux 3.1.
>> Disscussed on linux-kernel@vger.kernel.org "subject: [PATCH] TTY: pty, fix pty counting"
>> and not accepted.
>> Although, I think it's clear.
> 
> Ilya, is there some reason you are ignoring the tty maintainer and
> sending these to Linus directly?  These patches need to be tested in
> linux-next, so at the earliest, they can be merged into Linus's tree for
> 3.3, they are NOT 3.2 material, especially given that they are not even
> accepted by the current tty developers.
> 
> So please work with us, and don't try to circumvent the existing
> process, it is not the way we work here.
> 
> Especially as this specific patch was already rejected, for very good
> reasons, why are you ignoring those reasons?
> 
> thanks,
> 
> greg k-h
> 


OK, I understand you rules. 
But I don't understand, what for, you accept patch(commit: 24d406a6bf736f7aebdc8fa0f0ec86e0890c6d24), 
where "pty" call tty_driver_remove_tty(), only for invoke its own route(pty_unix98_remove).

Thank you.
Ilya.

Re: [PATCH v2] TTY: pty, fix pty counting in "/proc/sys/kernel/pty/nr"

[Greg KH]

On Thu, Oct 27, 2011 at 05:07:20PM +0400, Ilya Zykov wrote:
> Greg KH wrote:
> 
> > On Thu, Oct 27, 2011 at 01:48:35PM +0400, Ilya Zykov wrote:
> >> Regression for commit: 24d406a6bf736f7aebdc8fa0f0ec86e0890c6d24
> >> Commit: 24d406a6b accepted in Linux 3.1.
> >> Disscussed on linux-kernel@vger.kernel.org "subject: [PATCH] TTY: pty, fix pty counting"
> >> and not accepted.
> >> Although, I think it's clear.
> > 
> > Ilya, is there some reason you are ignoring the tty maintainer and
> > sending these to Linus directly?  These patches need to be tested in
> > linux-next, so at the earliest, they can be merged into Linus's tree for
> > 3.3, they are NOT 3.2 material, especially given that they are not even
> > accepted by the current tty developers.
> > 
> > So please work with us, and don't try to circumvent the existing
> > process, it is not the way we work here.
> > 
> > Especially as this specific patch was already rejected, for very good
> > reasons, why are you ignoring those reasons?
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> 
> OK, I understand you rules. 
> But I don't understand, what for, you accept patch(commit:
> 24d406a6bf736f7aebdc8fa0f0ec86e0890c6d24), where "pty" call
> tty_driver_remove_tty(), only for invoke its own
> route(pty_unix98_remove).

Please work with Alan and Jiri to get their acceptance of your patch,
they are the ones that need to ack it before I will.

thanks,

greg k-h

Re: [PATCH v2] TTY: pty, fix pty counting in "/proc/sys/kernel/pty/nr"

[Ilya Zykov]

Greg KH wrote:

> On Thu, Oct 27, 2011 at 01:48:35PM +0400, Ilya Zykov wrote:
>> Regression for commit: 24d406a6bf736f7aebdc8fa0f0ec86e0890c6d24
>> Commit: 24d406a6b accepted in Linux 3.1.
>> Disscussed on linux-kernel@vger.kernel.org "subject: [PATCH] TTY: pty, fix pty counting"
>> and not accepted.
>> Although, I think it's clear.
> 
> Ilya, is there some reason you are ignoring the tty maintainer and
> sending these to Linus directly?  These patches need to be tested in
> linux-next, so at the earliest, they can be merged into Linus's tree for
> 3.3, they are NOT 3.2 material, especially given that they are not even
> accepted by the current tty developers.
> 
> So please work with us, and don't try to circumvent the existing
> process, it is not the way we work here.
> 
> Especially as this specific patch was already rejected, for very good
> reasons, why are you ignoring those reasons?
> 
> thanks,
> 
> greg k-h
> 


But I don't understand, what for, "pty" driver, calling tty_driver_remove_tty(), 
only for call its own function(pty_unix98_remove).


Thank you.
Ilya.