* BUG: pty.c in linux 2.6.31-rc5+
@ 2011-08-04 6:43 MRU.Ilya
2011-08-04 14:36 ` Greg KH
2011-08-04 18:56 ` Alan Cox
0 siblings, 2 replies; 5+ messages in thread
From: MRU.Ilya @ 2011-08-04 6:43 UTC (permalink / raw)
To: stable; +Cc: linux-kernel
Synchronic's line disciplines(ppp_synctty, hdlc) can't work with pseudo
terminals.
If frames send very fast from one side(master/slave) to other one,
frames merge in one (merge point "flip buffer") and the other side can
read only one big frame.
But sync line discipline need one frame in one read.
For push one frame to ldisc I propose small patch, but this regression for
commit e043e42bdb66885b3ac10d27a01ccb9972e2b0a3.
I don't find any mutexes and other things forbidden in not user context,
in function flush_to_ldisc() , and I think this patch
is true and this function can called from any context. But I not sure.
Relative commit 86d23a057e718f73adc15e463c643d6e014a19cd.
^ permalink raw reply [flat|nested] 5+ messages in thread
* BUG: pty.c in linux 2.6.31-rc5+
@ 2011-08-04 6:46 MRU.Ilya
2011-08-04 14:37 ` Greg KH
0 siblings, 1 reply; 5+ messages in thread
From: MRU.Ilya @ 2011-08-04 6:46 UTC (permalink / raw)
To: stable; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 688 bytes --]
Synchronic's line disciplines(ppp_synctty, hdlc) can't work with pseudo
terminals.
If frames send very fast from one side(master/slave) to other one,
frames merge in one (merge point "flip buffer") and the other side can
read only one big frame.
But sync line discipline need one frame in one read.
For push one frame to ldisc I propose small patch, but this regression for
commit e043e42bdb66885b3ac10d27a01ccb9972e2b0a3.
I don't find any mutexes and other things forbidden in not user context,
in function flush_to_ldisc() , and I think this patch
is true and this function can called from any context. But I not sure.
Relative commit 86d23a057e718f73adc15e463c643d6e014a19cd.
[-- Attachment #2: pty_set_low_latency.patch --]
[-- Type: text/plain, Size: 275 bytes --]
--- orig/pty.c 2011-07-13 07:29:43.000000000 +0400
+++ work/pty.c 2011-08-03 20:59:01.000000000 +0400
@@ -204,6 +204,7 @@
clear_bit(TTY_OTHER_CLOSED, &tty->link->flags);
set_bit(TTY_THROTTLED, &tty->flags);
retval = 0;
+ tty->low_latency = 1;
out:
return retval;
}
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: BUG: pty.c in linux 2.6.31-rc5+
2011-08-04 6:43 MRU.Ilya
@ 2011-08-04 14:36 ` Greg KH
2011-08-04 18:56 ` Alan Cox
1 sibling, 0 replies; 5+ messages in thread
From: Greg KH @ 2011-08-04 14:36 UTC (permalink / raw)
To: MRU.Ilya; +Cc: stable, linux-kernel
On Thu, Aug 04, 2011 at 10:43:19AM +0400, MRU.Ilya wrote:
> Synchronic's line disciplines(ppp_synctty, hdlc) can't work with
> pseudo terminals.
>
> If frames send very fast from one side(master/slave) to other one,
> frames merge in one (merge point "flip buffer") and the other side
> can read only one big frame.
> But sync line discipline need one frame in one read.
>
> For push one frame to ldisc I propose small patch, but this regression for
> commit e043e42bdb66885b3ac10d27a01ccb9972e2b0a3.
>
> I don't find any mutexes and other things forbidden in not user context,
> in function flush_to_ldisc() , and I think this patch
> is true and this function can called from any context. But I not sure.
>
> Relative commit 86d23a057e718f73adc15e463c643d6e014a19cd.
I don't see a patch here.
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read Documentation/stable_kernel_rules.txt
for how to do this properly.
</formletter>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: BUG: pty.c in linux 2.6.31-rc5+
2011-08-04 6:46 BUG: pty.c in linux 2.6.31-rc5+ MRU.Ilya
@ 2011-08-04 14:37 ` Greg KH
0 siblings, 0 replies; 5+ messages in thread
From: Greg KH @ 2011-08-04 14:37 UTC (permalink / raw)
To: MRU.Ilya; +Cc: stable, linux-kernel
On Thu, Aug 04, 2011 at 10:46:43AM +0400, MRU.Ilya wrote:
> Synchronic's line disciplines(ppp_synctty, hdlc) can't work with
> pseudo terminals.
>
> If frames send very fast from one side(master/slave) to other one,
> frames merge in one (merge point "flip buffer") and the other side
> can read only one big frame.
> But sync line discipline need one frame in one read.
>
> For push one frame to ldisc I propose small patch, but this regression for
> commit e043e42bdb66885b3ac10d27a01ccb9972e2b0a3.
>
> I don't find any mutexes and other things forbidden in not user context,
> in function flush_to_ldisc() , and I think this patch
> is true and this function can called from any context. But I not sure.
>
> Relative commit 86d23a057e718f73adc15e463c643d6e014a19cd.
>
>
> --- orig/pty.c 2011-07-13 07:29:43.000000000 +0400
> +++ work/pty.c 2011-08-03 20:59:01.000000000 +0400
> @@ -204,6 +204,7 @@
> clear_bit(TTY_OTHER_CLOSED, &tty->link->flags);
> set_bit(TTY_THROTTLED, &tty->flags);
> retval = 0;
> + tty->low_latency = 1;
I really don't think this is correct.
Also, you forgot to read Documentation/SubmittingPatches for how to
properly format and send a patch and who to send it to...
thanks,
greg k-h
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: BUG: pty.c in linux 2.6.31-rc5+
2011-08-04 6:43 MRU.Ilya
2011-08-04 14:36 ` Greg KH
@ 2011-08-04 18:56 ` Alan Cox
1 sibling, 0 replies; 5+ messages in thread
From: Alan Cox @ 2011-08-04 18:56 UTC (permalink / raw)
To: MRU.Ilya; +Cc: stable, linux-kernel
On Thu, 04 Aug 2011 10:43:19 +0400
"MRU.Ilya" <utdilya@mail.ru> wrote:
> Synchronic's line disciplines(ppp_synctty, hdlc) can't work with pseudo
> terminals.
Correct - tty devices do not support framing. This is intentional.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-08-04 18:56 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-08-04 6:46 BUG: pty.c in linux 2.6.31-rc5+ MRU.Ilya
2011-08-04 14:37 ` Greg KH
-- strict thread matches above, loose matches on Subject: below --
2011-08-04 6:43 MRU.Ilya
2011-08-04 14:36 ` Greg KH
2011-08-04 18:56 ` Alan Cox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox