Please, try this patch maybe it can help localize your problem.
drivers/tty/n_tty.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index 05e72be..28f15d0 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -230,6 +230,7 @@ static void
On 19.03.2013 18:26, Peter Hurley wrote:
Although the driver-side input path must update the available
buffer space, it should not reschedule itself. If space is still
available and the flip buffers are not empty, flush_to_ldisc()
will loop again.
Sounds reasonable to me.
Thank you.
Ilya
|
| tty-receive_room = left
receive_room is now updated with a stale calculation of the
available buffer space, and the subsequent work loop will likely
overwrite unread data in the input buffer.
Sounds reasonable to me.
Thank you.
Ilya Zykov li...@izyk.ru
--
To unsubscribe from
it be multithreaded?
I think yes, because on SMP schedule_work() can work on different CPU
paralleled.
What do you think about this race condition?
https://lkml.org/lkml/2011/11/7/98
Thank you.
Ilya Zykov li...@izyk.ru
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
I have little question about flush_to_ldisc().
Does can it be multithreaded?
I think yes, because on SMP schedule_work() can work on different CPU
paralleled.
Yes, the same work item can now run in parallel on SMP since Tejun Heo
re-did the workqueue implementation on 2.6.36 [Stefan
On 20.03.2013 21:20, Peter Hurley wrote:
As Ilya Zykov identified in his patch 'PROBLEM: Race condition in
tty buffer's function flush_to_ldisc()', a race condition exists
which allows a parallel flush_to_ldisc() to flush and free the tty
flip buffers while those buffers are in-use
On 20.03.2013 21:49, Peter Hurley wrote:
The motivation for changing the workqueue api to allow parallel work
items on SMP was to fix a class of deadlocks where forward progress
could not be made due to subtle dependencies between work items
(actually that potential still exists with
On 03.12.2012 13:54, Ilya Zykov wrote:
The root of problem is carelessly zeroing pointer(in function
__tty_buffer_flush()),
when another thread can use it. It can be cause of NULL pointer dereference.
Main idea of the patch, this is never release last (struct tty_buffer) in
the active
On 29.11.2012 17:54, Alan Cox wrote:
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index 6c9b7cd..4f02f9c 100644
--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -114,11 +114,14 @@ static void __tty_buffer_flush(struct tty_struct *tty)
{
struct
On 29.11.2012 17:54, Alan Cox wrote:
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index 6c9b7cd..4f02f9c 100644
--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -114,11 +114,14 @@ static void __tty_buffer_flush(struct tty_struct *tty)
{
struct
On 29.11.2012 17:54, Alan Cox wrote:
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index 6c9b7cd..4f02f9c 100644
--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -114,11 +114,14 @@ static void __tty_buffer_flush(struct tty_struct *tty)
{
struct
-by: Ilya Zykov i...@ilyx.ru
---
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index 6c9b7cd..4f02f9c 100644
--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -114,11 +114,14 @@ static void __tty_buffer_flush(struct tty_struct *tty)
{
struct tty_buffer
On 04.12.2012 11:07, Peter Hurley wrote:
This patch series addresses the causes of flush_to_ldisc accessing
the tty after freeing.
I think, it is have sense only if you can take effect,
with this patch or something like. I can't. :)
Signed-off-by: Ilya Zykov i...@ilyx.ru
---
diff --git
On 04.12.2012 12:53, Alan Cox wrote:
Main idea here - we never flash last (struct tty_buffer) in the
active buffer. Only data for ldisc. (tty-buf.head-read =
tty-buf.head-commit). At that moment driver can collect(write) data
in buffer without conflict.
This one I agree with (sorry it took
and buffer filling
In order to delete the unneeded locks any more.
Signed-off-by: Ilya Zykov i...@ilyx.ru
---
drivers/tty/tty_buffer.c | 96 +-
1 files changed, 27 insertions(+), 69 deletions(-)
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
On 01.12.2012 18:59, Peter Hurley wrote:
(cc'ing Ilya Zykov i...@ilyx.ru because the test jig below is based on
his test program from https://lkml.org/lkml/2012/11/29/368 -- just want
to give credit where credit is due)
On Fri, 2012-11-30 at 18:52 -0500, Sasha Levin wrote:
Still
and buffer filling
In order to delete the unneeded locks any more.
Signed-off-by: Ilya Zykov i...@ilyx.ru
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
Revert: tty: hold lock across tty buffer finding and buffer filling
Signed-off-by: Ilya Zykov i...@ilyx.ru
---
drivers/tty/tty_buffer.c | 94 +++---
1 files changed, 22 insertions(+), 72 deletions(-)
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty
tty: Correct tty buffer flush.
Signed-off-by: Ilya Zykov i...@ilyx.ru
---
drivers/tty/tty_buffer.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index 7602df8..8ad 100644
--- a/drivers/tty/tty_buffer.c
-buf.head-read = tty-buf.head-commit).
At that moment driver can collect(write) data in buffer without conflict.
It is repeat behavior of flush_to_ldisc(), only without feeding data to ldisc.
Signed-off-by: Ilya Zykov i...@ilyx.ru
---
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index
On 24.01.2013 2:36, Karthik Manamcheri wrote:
When the tty input buffer is full and thereby throttled,
flushing/resetting the read buffer should unthrottle to allow more
data to be received.
Signed-off-by: Karthik Manamcheri karthik.manamch...@ni.com
---
drivers/tty/n_tty.c | 2 ++
1
Ok, I have a ton of patches from you, lots of different threads, patches
with the same subject, and I don't know what one Alan agreed to.
So, can you please resend what Alan and you agree should be applied to
the tree?
I think only two important:
[PATCH v4] tty: Add driver unthrottle
filling
In order to delete the unneeded locks any more.
Signed-off-by: Ilya Zykov i...@ilyx.ru
---
drivers/tty/tty_buffer.c | 105 +-
1 files changed, 29 insertions(+), 76 deletions(-)
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index
up.
Signed-off-by: Ilya Zykov i...@ilyx.ru
---
drivers/tty/tty_ioctl.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/tty_ioctl.c b/drivers/tty/tty_ioctl.c
index 8481b29..cc0fc52 100644
--- a/drivers/tty/tty_ioctl.c
+++ b/drivers/tty/tty_ioctl.c
filling
In order to delete the unneeded locks any more.
Signed-off-by: Ilya Zykov i...@ilyx.ru
---
drivers/tty/tty_buffer.c | 92 +++---
1 files changed, 22 insertions(+), 70 deletions(-)
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index
Hello!
I don't expert, but
maybe it can help.
I test with:
while echo mem /sys/power/state; do sleep 2; done
in one X-terminal, in other I trying playing with keyboard.
(Without playing all right I use ext3.)
And sometimes:
WARNING: at drivers/tty/tty_buffer.c:427 flush_to_ldisc+0x52/0x192()
On 20.01.2013 2:51, Sedat Dilek wrote:
On Sat, Jan 19, 2013 at 11:43 PM, Ilya Zykov i...@ilyx.ru wrote:
Hello!
I don't expert, but
maybe it can help.
I test with:
while echo mem /sys/power/state; do sleep 2; done
in one X-terminal, in other I trying playing with keyboard.
(Without
What do I do wrong?
After: modprobe cpufreq_ondemand
I have:
WARNING: Error inserting freq_table
(/lib/modules/3.7.0-rc8-next-20121205-ttybuf.1+/kernel/drivers/cpufreq/freq_table.ko):
Unknown symbol in module, or unknown parameter (see dmesg)
FATAL: Error inserting cpufreq_ondemand
What do I do wrong?
After: modprobe cpufreq_ondemand
I have:
WARNING: Error inserting freq_table
(/lib/modules/3.7.0-rc8-next-20121205-ttybuf.1+/kernel/drivers/cpufreq/freq_table.ko):
Unknown symbol in module, or unknown parameter (see dmesg)
FATAL: Error inserting cpufreq_ondemand
On 05.12.2012 22:53, Ilya Zykov wrote:
What do I do wrong?
After: modprobe cpufreq_ondemand
I have:
WARNING: Error inserting freq_table
(/lib/modules/3.7.0-rc8-next-20121205-ttybuf.1+/kernel/drivers/cpufreq/freq_table.ko):
Unknown symbol in module, or unknown parameter (see dmesg
On 10.12.2012 3:08, Rafael J. Wysocki wrote:
On Sunday, December 09, 2012 09:17:04 PM Ilya Zykov wrote:
On 05.12.2012 22:53, Ilya Zykov wrote:
What do I do wrong?
After: modprobe cpufreq_ondemand
I have:
WARNING: Error inserting freq_table
(/lib/modules/3.7.0-rc8-next-20121205-ttybuf.1
On 10.12.2012 3:08, Rafael J. Wysocki wrote:
On Sunday, December 09, 2012 09:17:04 PM Ilya Zykov wrote:
On 05.12.2012 22:53, Ilya Zykov wrote:
What do I do wrong?
After: modprobe cpufreq_ondemand
I have:
WARNING: Error inserting freq_table
(/lib/modules/3.7.0-rc8-next-20121205-ttybuf.1
On 04.12.2012 11:07, Peter Hurley wrote:
The most common cause stems from the n_tty_close() path spuriously
scheduling buffer work, when the ldisc has already been halted.
This is fixed in 'tty: Don't reschedule buffer work while closing'
Thank you,
very useful.
Fix this:
WARNING: at
.
About 'tty: fix IRQ45: nobody cared':
We don't call tty_unthrottle() if release last filp - ('tty-count == 0')
In other case it must be safely. Maybe we have bug in other place.
Signed-off-by: Ilya Zykov i...@ilyx.ru
---
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index 26f0d0e..a783d0e
On 22.11.2012 1:30, Alan Cox wrote:
Function reset_buffer_flags() also invoked during the
ioctl(...,TCFLSH,..). At the time of request we can have full buffers
and throttled driver too. If we don't unthrottle driver, we can get
forever throttled driver, because after request, we will have
empty
On 22.11.2012 9:25, andrew mcgregor wrote:
On 11/22/2012 at 05:29 PM, in message 50adaa26.7080...@ilyx.ru, Ilya Zykov
i...@ilyx.ru wrote:
On 22.11.2012 4:47, andrew mcgregor wrote:
On 11/22/2012 at 10:39 AM, in message 50ad4a01.7060...@ilyx.ru, Ilya Zykov
i...@ilyx.ru wrote
On 22.11.2012 8:29, Ilya Zykov wrote:
On 22.11.2012 4:47, andrew mcgregor wrote:
On 11/22/2012 at 10:39 AM, in message 50ad4a01.7060...@ilyx.ru,
Ilya Zykov
i...@ilyx.ru wrote:
On 22.11.2012 1:30, Alan Cox wrote:
Function reset_buffer_flags() also invoked during the
ioctl(...,TCFLSH
On 22.11.2012 1:30, Alan Cox wrote:
Function reset_buffer_flags() also invoked during the
ioctl(...,TCFLSH,..). At the time of request we can have full buffers
and throttled driver too. If we don't unthrottle driver, we can get
forever throttled driver, because after request, we will have
empty
On 22.11.2012 4:47, andrew mcgregor wrote:
On 11/22/2012 at 10:39 AM, in message 50ad4a01.7060...@ilyx.ru, Ilya Zykov
i...@ilyx.ru wrote:
On 22.11.2012 1:30, Alan Cox wrote:
Function reset_buffer_flags() also invoked during the
ioctl(...,TCFLSH,..). At the time of request we can have full
On 22.11.2012 10:03, Ilya Zykov wrote:
On 22.11.2012 8:29, Ilya Zykov wrote:
On 22.11.2012 4:47, andrew mcgregor wrote:
On 11/22/2012 at 10:39 AM, in message 50ad4a01.7060...@ilyx.ru,
Ilya Zykov
i...@ilyx.ru wrote:
On 22.11.2012 1:30, Alan Cox wrote:
Function reset_buffer_flags() also
drivers and invoke tty_unthrottle()
in right moment only.
Signed-off-by: Ilya Zykov i...@ilyx.ru
---
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index 26f0d0e..f20b44a 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -173,6 +173,13 @@ static void reset_buffer_flags(struct
drivers and invoke tty_unthrottle()
in right moment only.
Signed-off-by: Ilya Zykov i...@ilyx.ru
---
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index 26f0d0e..f20b44a 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -173,6 +173,13 @@ static void reset_buffer_flags(struct
ldisc's layer.
2. It is simple overhead because we call ldisc's flush_buffer() at least two
times.
Signed-off-by: Ilya Zykov i...@ilyx.ru
---
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index a21dc8e..c4a0a6d 100644
--- a/drivers/tty/serial/serial_core.c
+++ b
up.
Signed-off-by: Ilya Zykov i...@ilyx.ru
---
diff --git a/drivers/tty/tty_ioctl.c b/drivers/tty/tty_ioctl.c
index 12b1fa0..a038be1 100644
--- a/drivers/tty/tty_ioctl.c
+++ b/drivers/tty/tty_ioctl.c
@@ -1098,10 +1098,12 @@ int tty_perform_flush(struct tty_struct *tty, unsigned
long arg
,..). Then there is no place to do writers
wake up.
Signed-off-by: Ilya Zykov i...@ilyx.ru
---
diff --git a/drivers/tty/tty_ioctl.c b/drivers/tty/tty_ioctl.c
index 12b1fa0..a038be1 100644
--- a/drivers/tty/tty_ioctl.c
+++ b/drivers/tty/tty_ioctl.c
@@ -1098,10 +1098,12 @@ int tty_perform_flush(struct tty_struct *tty
-by: Ilya Zykov i...@ilyx.ru
---
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 0fcfd98..d87f353 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1304,7 +1304,7 @@ static void uart_close(struct tty_struct *tty, struct
to do writers
wake up.
Signed-off-by: Ilya Zykov i...@ilyx.ru
---
diff --git a/drivers/tty/tty_ioctl.c b/drivers/tty/tty_ioctl.c
index 12b1fa0..4071a8f 100644
--- a/drivers/tty/tty_ioctl.c
+++ b/drivers/tty/tty_ioctl.c
@@ -1096,12 +1096,16 @@ int tty_perform_flush(struct tty_struct *tty, unsigned
On 27.11.2012 21:24, Greg Kroah-Hartman wrote:
On Tue, Nov 27, 2012 at 10:14:33AM +0400, Ilya Zykov wrote:
Sorry. More correct.
In what way? Should I wait for the 6th version? :)
thanks,
greg k-h
No, if only you will accept:
[PATCH]tty: Incorrect use tty_ldisc_flush() in TTY
.
Signed-off-by: Ilya Zykov i...@ilyx.ru
---
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index 6c9b7cd..4f02f9c 100644
--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -114,11 +114,14 @@ static void __tty_buffer_flush(struct tty_struct *tty)
{
struct
-by: Ilya Zykov i...@ilyx.ru
---
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index 6c9b7cd..4f02f9c 100644
--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -114,11 +114,14 @@ static void __tty_buffer_flush(struct tty_struct *tty)
{
struct tty_buffer *thead
* Copyright (C) 2012 Ilya Zykov
*
* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, either version 2 of the License, or
* (at your option) any later version
We should not write toward the closed pty.
Now it happens, if one side close last file descriptor,
and other side in this moment write to it.
It also prevents scheduling unnecessary work.
Signed-off-by: Ilya Zykov i...@ilyx.ru
---
drivers/tty/pty.c |2 ++
1 files changed, 2 insertions(+), 0
When we are opening ptmx, we have closed pts, by description.
Now only if we open and after close all pts' descriptions, pty_close() sets
this bit correctly
Signed-off-by: Ilya Zykov i...@ilyx.ru
---
drivers/tty/pty.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git
On 19.12.2012 23:10, Alan Cox wrote:
diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c
index a82b399..1ce1362 100644
--- a/drivers/tty/pty.c
+++ b/drivers/tty/pty.c
@@ -116,6 +116,8 @@ static int pty_space(struct tty_struct *to)
static int pty_write(struct tty_struct *tty, const
Please, try this patch maybe it can help localize your problem.
drivers/tty/n_tty.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index 05e72be..28f15d0 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -230,6 +230,7 @@ static void
o me.
Thank you.
Ilya Zykov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
| tty->receive_room = left
>
> receive_room is now updated with a stale calculation of the
> available buffer space, and the subsequent work loop will likely
> overwrite unread data in the input buffer.
>
Sounds reasonable to me.
Thank you.
Ilya Zykov
e question about flush_to_ldisc().
Does can it be multithreaded?
I think yes, because on SMP schedule_work() can work on different CPU
paralleled.
What do you think about this race condition?
https://lkml.org/lkml/2011/11/7/98
Thank you.
Ilya Zykov
--
To unsubscribe from this list:
>> I have little question about flush_to_ldisc().
>> Does can it be multithreaded?
>>
>> I think yes, because on SMP schedule_work() can work on different CPU
>> paralleled.
>
> Yes, the same work item can now run in parallel on SMP since Tejun Heo
> re-did the workqueue implementation on 2.6.36
On 20.03.2013 21:20, Peter Hurley wrote:
> As Ilya Zykov identified in his patch 'PROBLEM: Race condition in
> tty buffer's function flush_to_ldisc()', a race condition exists
> which allows a parallel flush_to_ldisc() to flush and free the tty
> flip buffers while those buffer
On 20.03.2013 21:49, Peter Hurley wrote:
> The motivation for changing the workqueue api to allow parallel work
> items on SMP was to fix a class of deadlocks where forward progress
> could not be made due to subtle dependencies between work items
> (actually that potential still exists with
On 03.12.2012 13:54, Ilya Zykov wrote:
> The root of problem is carelessly zeroing pointer(in function
> __tty_buffer_flush()),
> when another thread can use it. It can be cause of "NULL pointer dereference".
> Main idea of the patch, this is never release l
On 29.11.2012 17:54, Alan Cox wrote:
>> diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
>> index 6c9b7cd..4f02f9c 100644
>> --- a/drivers/tty/tty_buffer.c
>> +++ b/drivers/tty/tty_buffer.c
>> @@ -114,11 +114,14 @@ static void __tty_buffer_flush(struct tty_struct *tty)
>> {
>>
On 29.11.2012 17:54, Alan Cox wrote:
>> diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
>> index 6c9b7cd..4f02f9c 100644
>> --- a/drivers/tty/tty_buffer.c
>> +++ b/drivers/tty/tty_buffer.c
>> @@ -114,11 +114,14 @@ static void __tty_buffer_flush(struct tty_struct *tty)
>> {
>>
On 29.11.2012 17:54, Alan Cox wrote:
>> diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
>> index 6c9b7cd..4f02f9c 100644
>> --- a/drivers/tty/tty_buffer.c
>> +++ b/drivers/tty/tty_buffer.c
>> @@ -114,11 +114,14 @@ static void __tty_buffer_flush(struct tty_struct *tty)
>> {
>>
sta...@vger.kernel.org
Signed-off-by: Ilya Zykov
---
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index 6c9b7cd..4f02f9c 100644
--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -114,11 +114,14 @@ static void __tty_buffer_flush(struct tty_struct *tty)
{
st
On 04.12.2012 11:07, Peter Hurley wrote:
> This patch series addresses the causes of flush_to_ldisc accessing
> the tty after freeing.
>
I think, it is have sense only if you can take effect,
with this patch or something like. I can't. :)
Signed-off-by: Ilya Zykov
---
diff --git a/dr
On 04.12.2012 12:53, Alan Cox wrote:
>> Main idea here - we never flash last (struct tty_buffer) in the
>> active buffer. Only data for ldisc. (tty->buf.head->read =
>> tty->buf.head->commit). At that moment driver can collect(write) data
>> in buffer without conflict.
>
> This one I agree with
oss tty buffer finding and buffer filling
In order to delete the unneeded locks any more.
Signed-off-by: Ilya Zykov
---
drivers/tty/tty_buffer.c | 96 +-
1 files changed, 27 insertions(+), 69 deletions(-)
diff --git a/drivers/tty/tty_buffer.c b/drivers/
On 01.12.2012 18:59, Peter Hurley wrote:
> (cc'ing Ilya Zykov because the test jig below is based on
> his test program from https://lkml.org/lkml/2012/11/29/368 -- just want
> to give credit where credit is due)
>
> On Fri, 2012-11-30 at 18:52 -0500, Sasha Levin wrote:
>>
oss tty buffer finding and buffer filling
In order to delete the unneeded locks any more.
Signed-off-by: Ilya Zykov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
Revert: tty: hold lock across tty buffer finding and buffer filling
Signed-off-by: Ilya Zykov
---
drivers/tty/tty_buffer.c | 94 +++---
1 files changed, 22 insertions(+), 72 deletions(-)
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
tty: Correct tty buffer flush.
Signed-off-by: Ilya Zykov
---
drivers/tty/tty_buffer.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index 7602df8..8ad 100644
--- a/drivers/tty/tty_buffer.c
+++ b/drivers
ldisc(tty->buf.head->read = tty->buf.head->commit).
At that moment driver can collect(write) data in buffer without conflict.
It is repeat behavior of flush_to_ldisc(), only without feeding data to ldisc.
Signed-off-by: Ilya Zykov
---
diff --git a/drivers/tty/tty_buffer.c b/drivers/
What do I do wrong?
After: modprobe cpufreq_ondemand
I have:
WARNING: Error inserting freq_table
(/lib/modules/3.7.0-rc8-next-20121205-ttybuf.1+/kernel/drivers/cpufreq/freq_table.ko):
Unknown symbol in module, or unknown parameter (see dmesg)
FATAL: Error inserting cpufreq_ondemand
What do I do wrong?
After: modprobe cpufreq_ondemand
I have:
WARNING: Error inserting freq_table
(/lib/modules/3.7.0-rc8-next-20121205-ttybuf.1+/kernel/drivers/cpufreq/freq_table.ko):
Unknown symbol in module, or unknown parameter (see dmesg)
FATAL: Error inserting cpufreq_ondemand
On 05.12.2012 22:53, Ilya Zykov wrote:
> What do I do wrong?
>
> After: modprobe cpufreq_ondemand
> I have:
>
> WARNING: Error inserting freq_table
> (/lib/modules/3.7.0-rc8-next-20121205-ttybuf.1+/kernel/drivers/cpufreq/freq_table.ko):
> Unknown symbol in module, o
On 10.12.2012 3:08, Rafael J. Wysocki wrote:
> On Sunday, December 09, 2012 09:17:04 PM Ilya Zykov wrote:
>> On 05.12.2012 22:53, Ilya Zykov wrote:
>>> What do I do wrong?
>>>
>>> After: modprobe cpufreq_ondemand
>>> I have:
>>>
>>> W
On 10.12.2012 3:08, Rafael J. Wysocki wrote:
> On Sunday, December 09, 2012 09:17:04 PM Ilya Zykov wrote:
>> On 05.12.2012 22:53, Ilya Zykov wrote:
>>> What do I do wrong?
>>>
>>> After: modprobe cpufreq_ondemand
>>> I have:
>>>
>>> W
On 04.12.2012 11:07, Peter Hurley wrote:
>
> The most common cause stems from the n_tty_close() path spuriously
> scheduling buffer work, when the ldisc has already been halted.
> This is fixed in 'tty: Don't reschedule buffer work while closing'
Thank you,
very useful.
Fix this:
WARNING: at
On 24.01.2013 2:36, Karthik Manamcheri wrote:
> When the tty input buffer is full and thereby throttled,
> flushing/resetting the read buffer should unthrottle to allow more
> data to be received.
>
> Signed-off-by: Karthik Manamcheri
> ---
> drivers/tty/n_tty.c | 2 ++
> 1 file changed, 2
ldisc's layer.
2. It is simple overhead because we call ldisc's flush_buffer() at least two
times.
Signed-off-by: Ilya Zykov
---
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index a21dc8e..c4a0a6d 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty
no place to do writers
wake up.
Signed-off-by: Ilya Zykov
---
diff --git a/drivers/tty/tty_ioctl.c b/drivers/tty/tty_ioctl.c
index 12b1fa0..a038be1 100644
--- a/drivers/tty/tty_ioctl.c
+++ b/drivers/tty/tty_ioctl.c
@@ -1098,10 +1098,12 @@ int tty_perform_flush(struct tty_struct *tty, unsigned
ide do ioctl(...,TCFLSH,..). Then there is no place to do writers
wake up.
Signed-off-by: Ilya Zykov
---
diff --git a/drivers/tty/tty_ioctl.c b/drivers/tty/tty_ioctl.c
index 12b1fa0..a038be1 100644
--- a/drivers/tty/tty_ioctl.c
+++ b/drivers/tty/tty_ioctl.c
@@ -1098,10 +1098,12 @@ int tty_perform_flush
s?
Signed-off-by: Ilya Zykov
---
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 0fcfd98..d87f353 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1304,7 +1304,7 @@ static void uart_close(struct tty_struct *tty, struct
ide do ioctl(...,TCFLSH,..). Then there is no place to do writers
wake up.
Signed-off-by: Ilya Zykov
---
diff --git a/drivers/tty/tty_ioctl.c b/drivers/tty/tty_ioctl.c
index 12b1fa0..4071a8f 100644
--- a/drivers/tty/tty_ioctl.c
+++ b/drivers/tty/tty_ioctl.c
@@ -1096,12 +1096,16 @@ int tty_perform_flush(struct tty_stru
On 27.11.2012 21:24, Greg Kroah-Hartman wrote:
> On Tue, Nov 27, 2012 at 10:14:33AM +0400, Ilya Zykov wrote:
>> Sorry. More correct.
>
> In what way? Should I wait for the 6th version? :)
>
> thanks,
>
> greg k-h
>
No, if only you will accept:
[PATCH]tty:
.
Signed-off-by: Ilya Zykov
---
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index 6c9b7cd..4f02f9c 100644
--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -114,11 +114,14 @@ static void __tty_buffer_flush(struct tty_struct *tty)
{
struct tty_buffer *thead
-by: Ilya Zykov
---
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index 6c9b7cd..4f02f9c 100644
--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -114,11 +114,14 @@ static void __tty_buffer_flush(struct tty_struct *tty)
{
struct tty_buffer *thead
to do writers
wake up.
About 'tty: fix "IRQ45: nobody cared"':
We don't call tty_unthrottle() if release last filp - ('tty->count == 0')
In other case it must be safely. Maybe we have bug in other place.
Signed-off-by: Ilya Zykov
---
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n
On 22.11.2012 1:30, Alan Cox wrote:
Function reset_buffer_flags() also invoked during the
ioctl(...,TCFLSH,..). At the time of request we can have full buffers
and throttled driver too. If we don't unthrottle driver, we can get
forever throttled driver, because after request, we will have
empty
On 22.11.2012 9:25, andrew mcgregor wrote:
On 11/22/2012 at 05:29 PM, in message <50adaa26.7080...@ilyx.ru>, Ilya Zykov
wrote:
On 22.11.2012 4:47, andrew mcgregor wrote:
On 11/22/2012 at 10:39 AM, in message <50ad4a01.7060...@ilyx.ru>, Ilya Zykov
wrote:
On 22.11.2012 1:
On 22.11.2012 8:29, Ilya Zykov wrote:
On 22.11.2012 4:47, andrew mcgregor wrote:
On 11/22/2012 at 10:39 AM, in message <50ad4a01.7060...@ilyx.ru>,
Ilya Zykov
wrote:
On 22.11.2012 1:30, Alan Cox wrote:
Function reset_buffer_flags() also invoked during the
ioctl(...,TCFLSH,..). At th
On 22.11.2012 1:30, Alan Cox wrote:
Function reset_buffer_flags() also invoked during the
ioctl(...,TCFLSH,..). At the time of request we can have full buffers
and throttled driver too. If we don't unthrottle driver, we can get
forever throttled driver, because after request, we will have
empty
On 22.11.2012 4:47, andrew mcgregor wrote:
On 11/22/2012 at 10:39 AM, in message <50ad4a01.7060...@ilyx.ru>, Ilya Zykov
wrote:
On 22.11.2012 1:30, Alan Cox wrote:
Function reset_buffer_flags() also invoked during the
ioctl(...,TCFLSH,..). At the time of request we can have full b
On 22.11.2012 10:03, Ilya Zykov wrote:
On 22.11.2012 8:29, Ilya Zykov wrote:
On 22.11.2012 4:47, andrew mcgregor wrote:
On 11/22/2012 at 10:39 AM, in message <50ad4a01.7060...@ilyx.ru>,
Ilya Zykov
wrote:
On 22.11.2012 1:30, Alan Cox wrote:
Function reset_buffer_flags() also i
count).
This Patch help us catch bugs in tty's drivers and invoke tty_unthrottle()
in right moment only.
Signed-off-by: Ilya Zykov
---
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index 26f0d0e..f20b44a 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -173,6 +173,13 @
count).
This Patch help us catch bugs in tty's drivers and invoke tty_unthrottle()
in right moment only.
Signed-off-by: Ilya Zykov
---
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index 26f0d0e..f20b44a 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -173,6 +173,13 @
2/0x17
---
/*
* stress_test_tty.c
*
* Created on: Dec, 2012
* Copyright (C) 2012 Ilya Zykov
*
* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, either version 2 of the License, or
* (a
We should not write toward the closed pty.
Now it happens, if one side close last file descriptor,
and other side in this moment write to it.
It also prevents scheduling unnecessary work.
Signed-off-by: Ilya Zykov
---
drivers/tty/pty.c |2 ++
1 files changed, 2 insertions(+), 0 deletions
1 - 100 of 108 matches
Mail list logo
