completely asynch kworker, kicked
off from interrupt context.
Fixes: 28a821c30688 ("Staging: speakup: Update __speakup_paste_selection()
tty (ab)usage to match vt")
Cc:
Signed-off-by: Peter Hurley
---
drivers/staging/speakup/selection.c | 4 +++-
1 file changed, 3 insertions(+),
current ldisc via tty->ldisc is
unsafe; the ldisc ptr dereferenced may be stale if the line discipline
is changing via ioctl(TIOCSETD) or hangup.
Wait for the line discipline reference (just like read() or write())
to retrieve the "current" line discipline id.
Cc:
Signed-off-by:
tty->link essentially open-codes tty_wakeup(), just replace with the
equivalent tty_wakeup().
Cc:
Signed-off-by: Peter Hurley
---
drivers/tty/n_tty.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index 2dddc72..703b219 100644
---
/aoe/aoecmd.c:1302
[] ret_from_fork+0x3f/0x70 arch/x86/entry/entry_64.S:468
Code: Bad RIP value.
RIP [< (null)>] (null)
RSP
CR2:
---[ end trace a587f8947e54d6ea ]---
Reported-by: Dmitry Vyukov
Cc:
Signed-off-by: Peter Hurley
---
driv
-by: Dmitry Vyukov
Cc:
Signed-off-by: Peter Hurley
---
drivers/net/irda/irtty-sir.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/net/irda/irtty-sir.c b/drivers/net/irda/irtty-sir.c
index 696852e..7a3f990 100644
--- a/drivers/net/irda/irtty-sir.c
+++ b/drivers/net/ird
ioctl.c:43 fs/ioctl.c:607)
[ 634.427491] SyS_ioctl (fs/ioctl.c:622 fs/ioctl.c:613)
[ 634.427945] entry_SYSCALL_64_fastpath (arch/x86/entry/entry_64.S:188)
Reported-and-tested-by: Sasha Levin
Cc:
Signed-off-by: Peter Hurley
---
drivers/net/wan/x25_asy.c | 6 +-
1 file changed, 1 in
6, *nr += 5
Because the scan limit is now bumped +1 byte, when the scan is
completed, the tail advance and the user buffer copy limit is
re-clamped to *nr when EOF is _not_ found.
Fixes: 40d5e0905a03 ("n_tty: Fix EOF push handling")
Cc: # 3.12+
Signed-off-by: Peter Hurley
The correct lock order is atomic_write_lock => termios_rwsem, as
established by tty_write() => n_tty_write().
Fixes: c274f6ef1c666 ("tty: Hold termios_rwsem for tcflow(TCIxxx)")
Reported-and-Tested-by: Dmitry Vyukov
Cc: # v3.18+
Signed-off-by: Peter Hurley
---
drivers/tty
The data to audit/record is in the 'from' buffer (ie., the input
read buffer).
Fixes: 72586c6061ab ("n_tty: Fix auditing support for cannonical mode")
Cc: Laura Abbott
Cc: Miloslav Trmač
Cc:
Signed-off-by: Peter Hurley
---
v2: Fix rebase error, !CONFIG_AUDIT build fix
On 11/08/2015 08:01 AM, kbuild test robot wrote:
> Hi Peter,
>
> [auto build test WARNING on: v4.3-rc7]
> [also build test WARNING on: next-20151106]
>
> url:
> https://github.com/0day-ci/linux/commits/Peter-Hurley/tty-audit-Fix-audit-source/20151108-205330
> config
The data to audit/record is in the 'from' buffer (ie., the input
read buffer).
Fixes: 72586c6061ab ("n_tty: Fix auditing support for cannonical mode")
Cc: Laura Abbott
Cc: Miloslav Trmač
Cc:
Signed-off-by: Peter Hurley
---
drivers/tty/n_tty.c | 2 +-
drivers
On 09/21/2015 09:38 AM, Tilman Schmidt wrote:
> Am 21.09.2015 um 15:13 schrieb Peter Hurley:
>> On 09/18/2015 08:38 AM, Tilman Schmidt wrote:
>>> Am 17.09.2015 um 20:13 schrieb Peter Hurley:
>>>> On Wed, Sep 16, 2015 at 7:26 AM, Tilman Schmidt wrote:
> [...]
On 09/18/2015 08:38 AM, Tilman Schmidt wrote:
> Am 17.09.2015 um 20:13 schrieb Peter Hurley:
>> On Wed, Sep 16, 2015 at 7:26 AM, Tilman Schmidt wrote:
>>> Am 16.09.2015 um 03:18 schrieb Peter Hurley:
>>>> On Tue, Sep 15, 2015 at 8:37 PM, Tilman Schmidt wrote:
>&g
On Wed, Sep 16, 2015 at 7:26 AM, Tilman Schmidt wrote:
> Am 16.09.2015 um 03:18 schrieb Peter Hurley:
>> On Tue, Sep 15, 2015 at 8:37 PM, Tilman Schmidt wrote:
>>> Am 16.09.2015 um 01:08 schrieb Peter Hurley:
>>>> On Tue, Sep 15, 2015 at 10:22 AM, Jiri Slaby wro
On Tue, Sep 15, 2015 at 8:37 PM, Tilman Schmidt wrote:
> Am 16.09.2015 um 01:08 schrieb Peter Hurley:
>> On Tue, Sep 15, 2015 at 10:22 AM, Jiri Slaby > <mailto:jsl...@suse.cz>> wrote:
>>
>> From: Tilman Schmidt
>>
>> 3.12-stable review pat
Hi Joseph,
On 04/15/2015 01:39 PM, Joseph Salisbury wrote:
> From: Peter Hurley
>
> BugLink: http://bugs.launchpad.net/bugs/1381005
>
> In canon mode, the read buffer head will advance over the buffer tail
> if the input > 4095 bytes without receiving a line terminati
problem is that irq_create_mapping()/irq_dispose_mapping()
is not symmetrical, which breaks the device probe model. With that
fixed, no change would be required here.
Regards,
Peter Hurley
> Signed-off-by: Michal Simek
> CC:
> ---
>
> Changes in v2:
> - Extend patch d
On 04/13/2015 01:24 PM, Peter Hurley wrote:
> A read() from a pty master may mistakenly indicate EOF (errno == -EIO)
> after the pty slave has closed, even though input data remains to be read.
> For example,
>
>pty slave |input worker
//bugzilla.kernel.org/show_bug.cgi?id=96311
BugLink: http://bugs.launchpad.net/bugs/1429756
Cc: # 3.19+
Reported-by: Andy Whitcroft
Reported-by: H.J. Lu
Signed-off-by: Peter Hurley
---
v3: Fix race w/ pty_open()
Fix ordering of TTY_OTHER_DONE wrt head index
v2: Clear TTY_OTHER_DONE on
Is there some kind of probe problem you're trying to address?
Are you trying to silence the error message?
> When PORT_UNKNOWN probe will fail anyway.
Ok, but doesn't device_attach() just continue to try to match other
drivers on the platform bus?
Regards,
Peter Hurley
>
Self-review
On 04/09/2015 09:38 PM, Peter Hurley wrote:
> A read() from a pty master may mistakenly indicate EOF (errno == -EIO)
> after the pty slave has closed, even though input data remains to be read.
> For example,
>
>pty slave |input worker
On 04/09/2015 01:43 PM, H.J. Lu wrote:
> On Thu, Apr 9, 2015 at 7:54 AM, Peter Hurley wrote:
>> A read() from a pty master may mistakenly indicate EOF (errno == -EIO)
>> after the pty slave has closed, even though input data remains to be read.
>> For example,
&
//bugzilla.kernel.org/show_bug.cgi?id=96311
BugLink: http://bugs.launchpad.net/bugs/1429756
Cc: # 3.19+
Reported-by: Andy Whitcroft
Reported-by: H.J. Lu
Signed-off-by: Peter Hurley
---
Documentation/serial/tty.txt | 3 +++
drivers/tty/n_hdlc.c | 4 ++--
drivers/tty/n_tty.c
string and failure to match
console; I'm not sure if there are other unexpected consequences.
Signed-off-by: Peter Hurley
Signed-off-by: Greg Kroah-Hartman
[pjh: backport for 3.10- (fixes 2.6.22+)]
Signed-off-by: Peter Hurley
---
kernel/printk.c | 4 +++-
1 file changed, 3 insertions(+), 1 de
s, the patent notice in the
specification is a barrier, and it would be helpful to your cause if
Microsoft cited the patent numbers, but you could also just explain these
in your cover letter at submission time.
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscr
On 03/17/2015 08:13 PM, Jon Masters wrote:
> Hi Peter,
>
> On 03/17/2015 01:47 PM, Peter Hurley wrote:
>
>> On 03/17/2015 12:48 PM, Jon Masters wrote:
>>> On 03/16/2015 03:46 PM, Peter Hurley wrote:
>>>> On 03/16/2015 02:35 PM, Hans de Goede wrote:
>>
On 03/17/2015 10:20 AM, Peter Hurley wrote:
> On 03/17/2015 09:43 AM, Hans de Goede wrote:
>> Hi,
>>
>> On 17-03-15 14:30, Rob Herring wrote:
>>> On Tue, Mar 17, 2015 at 3:20 AM, Hans de Goede wrote:
>>
>>
>>
>>>> TBH I do not
On 03/17/2015 03:44 PM, Peter Hurley wrote:
> On 03/17/2015 03:35 PM, Andreas Schwab wrote:
>> Peter Hurley writes:
>>
>>> It doesn't boot?
>>
>> It boots right into user space, but the initrd doesn't like something
>> (perhaps the missing conso
On 03/17/2015 03:35 PM, Andreas Schwab wrote:
> Peter Hurley writes:
>
>> It doesn't boot?
>
> It boots right into user space, but the initrd doesn't like something
> (perhaps the missing console) and exits. Note that the framebuffer
> console does wo
Hi Jon,
On 03/17/2015 12:48 PM, Jon Masters wrote:
> On 03/16/2015 03:46 PM, Peter Hurley wrote:
>> On 03/16/2015 02:35 PM, Hans de Goede wrote:
>>> To be clear about my aarch64 remark, that relates to the behavior of
>>> aarch64 acpi using
>>> machines, tho
h the most troubleshooting info right now
implicates some buffer overflow or console mismanagement triggered by simply
having defined a preferred console. This needs to be figured out regardless,
and this is what I'm working right now.
2. Hans' use-case was _already broken_ even b
On 03/16/2015 08:35 PM, Andreas Schwab wrote:
> Peter Hurley writes:
>
>> On 03/16/2015 08:19 PM, Andreas Schwab wrote:
>>> Peter Hurley writes:
>>>
>>>> I don't see this as a regression, but rather a misconfiguration.
>>>
>>> It
On 03/16/2015 08:19 PM, Andreas Schwab wrote:
> Peter Hurley writes:
>
>> I don't see this as a regression, but rather a misconfiguration.
>
> It breaks booting on PowerMac.
It doesn't boot?
--
To unsubscribe from this list: send the line "unsubscribe st
On 03/16/2015 02:35 PM, Hans de Goede wrote:
> Hi,
>
> On 16-03-15 19:23, Peter Hurley wrote:
>> On 03/16/2015 02:12 PM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 16-03-15 18:49, Peter Hurley wrote:
>>>> Hi Hans,
>>>>
>>>>
so won't suffer from this breakage.
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/16/2015 02:12 PM, Hans de Goede wrote:
> Hi,
>
> On 16-03-15 18:49, Peter Hurley wrote:
>> Hi Hans,
>>
>> On 03/16/2015 12:31 PM, Hans de Goede wrote:
>>> Hi All,
>>>
>>> While updating my local working tree to 4.0-rc4 this morning I
controllable across different
subsystems (or if there were consoles defined with the arch itself).
That said, I'll look into fixing your use-case automagically without requiring
configuration changes.
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
implementation is not affected
> by this bug due to a lucky chance (comparison to an unsigned maximum
> timeout), and neither is the cyclades one that had an explicit check for
> negative timeouts, but all other tty drivers appear to be affected.
Reviewed-by: Peter Hurley
--
To unsubscribe
le options with
stdout-path") added options string support to the stdout-path property,
which broke earlycon.
Add the same support to fdt_path_offset() so earlycon can parse and
process stdout-path properties containing an options string.
Cc: Leif Lindholm
Cc: # 3.19+
Signed-off-by: Peter
On 03/01/2015 10:44 AM, Kevin Cernekee wrote:
[...]
> Whoops, I had no clue userland cared about these... thanks for the fix.
Yeah, totally non-obvious.
That's why my other patch redefines these with the uapi identifiers.
Regards,
Peter Hurley
--
To unsubscribe from this list: send
commit 3ffb1a8193bea ("serial: core: Add big-endian iotype")
re-numbered userspace-dependent values; ioctl(TIOCSSERIAL) can
assign the port iotype (which is expected to match the selected
i/o accessors), so iotype values must not be changed.
Cc: Kevin Cernekee
Cc: # 3.19+
Signed-off
there are other unexpected consequences.
Cc: # 2.6.22+
Signed-off-by: Peter Hurley
---
kernel/printk/console_cmdline.h | 2 +-
kernel/printk/printk.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/printk/console_cmdline.h b/kernel/printk/console_cmdline.h
index c
On 02/14/2015 02:28 PM, Linus Torvalds wrote:
> On Tue, Jan 20, 2015 at 11:14 AM, Peter Hurley
> wrote:
>>
>> Yeah, gmail is broken that way. I hope they fix it soon.
>>
>> It's even more annoying when the email is _addressed_ to you and the
>> first emai
On 02/10/2015 11:38 AM, Paul E. McKenney wrote:
> On Tue, Feb 10, 2015 at 09:03:50AM -0500, Peter Hurley wrote:
>> On 02/06/2015 09:08 PM, Mathieu Desnoyers wrote:
>>> A lockless_dereference() appears to be missing in llist_del_first().
>>> It should only m
@@
> #include
> #include
> #include
> +#include
Pranith,
I didn't realize you put lockless_dereference() in rcupdate.h
If the point of lockless_reference() is to provide a utility function for
situations _not_ involving RCU, then it doesn't make sense to provide it
in
On 01/20/2015 03:35 AM, Jiri Slaby wrote:
> Ok, I see now. The rest of the thread ended up in the stable mailbox.
Yeah, gmail is broken that way. I hope they fix it soon.
It's even more annoying when the email is _addressed_ to you and the
first email you get comes from a list so the server filte
On 01/19/2015 01:25 PM, Theodore Ts'o wrote:
> On Mon, Jan 19, 2015 at 01:00:03PM -0500, Peter Hurley wrote:
>>>> --- a/drivers/tty/pty.c
>>>> +++ b/drivers/tty/pty.c
>>>> @@ -210,6 +210,9 @@ static int pty_signal(struct tty_struct *tty, i
if this exploit currently exists.
Limit to signals actually used.
Cc: Theodore Ts'o
Cc: Howard Chu
Cc: One Thousand Gnomes
Cc: Jiri Slaby
Cc: # 2.6.36+
Signed-off-by: Peter Hurley
---
v2: Fixed stupidity.
drivers/tty/pty.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers
On 01/19/2015 12:57 PM, Howard Chu wrote:
> Peter Hurley wrote:
>> Commit 26df6d13406d1a5 ("tty: Add EXTPROC support for LINEMODE")
>> allows a process which has opened a pty master to send _any_ signal
>> to the process group of the pty slave. Although potentiall
if this exploit currently exists.
Limit to signals actually used.
Cc: Theodore Ts'o
Cc: Howard Chu
Cc: One Thousand Gnomes
Cc: Jiri Slaby
Cc: # 2.6.36+
Signed-off-by: Peter Hurley
---
drivers/tty/pty.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/tty/pty.c b/dri
[ reviewing my own patch :) ]
On 12/30/2014 07:05 AM, Peter Hurley wrote:
> Add commit_head buffer index, which the producer-side publishes
> after input processing. This ensures the consumer-side observes
> correctly-ordered writes in raw mode (ie., the buffer data is
> written befor
> On Tue, Dec 30, 2014 at 1:05 PM, Peter Hurley
> wrote:
>> Add commit_head buffer index, which the producer-side publishes
>> after input processing. This ensures the consumer-side observes
>> correctly-ordered writes in raw mode
>
> I understand that the commit_
Hi Christian,
On 01/01/2015 08:55 AM, Christian Riesch wrote:
> On Thu, Jan 1, 2015 at 12:00 PM, Christian Riesch >> @@ -164,15
> +160,17 @@ static inline int tty_put_user(struct tty_struct *tty,
> unsigned char x,
>>> static int receive_room(struct tty_struct *tty)
>>> {
>>> struct n_tt
8e5f4584269d913dd
My apologies for not cc'ing you on that fix.
https://lkml.org/lkml/2014/12/30/66
However, it requires 3.14+. I still need to backport it to 3.12.
Regards,
Peter Hurley
>
>
>
> Denis Du
>
>
> ----- Original Message -
> From: Peter Hurley
() and in n_tty_ioctl(); in this
circumstance, commit_head is equivalent to read_head.
Cc: Christian Riesch
Cc: # v3.14.x (will need backport to v3.12.x)
Signed-off-by: Peter Hurley
---
drivers/tty/n_tty.c | 80 ++---
1 file changed, 40 insertions
rrier instructions.
>>>
>>> Yes, but "order" matters.
>>>
>>> If I write code that does:
>>>
>>> 100 x = ldata->read_head;
>>> 101 &ldata->read_head[x & SOME_VALUE] = y;
>>> 102 ldata->read_head+
Only print one warning when a task is on the read_wait or write_wait
wait queue at final tty release.
Cc: # 3.4.x+
Signed-off-by: Peter Hurley
---
drivers/tty/tty_io.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index
forever (but still killable).
NB: killable just allows for the task to be rewoken manually, not
to be terminated.
Cc: # since before 2.6.32
Signed-off-by: Peter Hurley
---
drivers/tty/tty_io.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/tty_io.c b/drivers
al /dev/ttyS0 spd_hi base_baud 38400
Only perform the "magic" 38400 -> SPD_* baud transform on the first
loop iteration, which prevents the degenerate case from recognizing
the clamped baud rate as the "magic" 38400 value.
Reported-by: Robert Święcki
Cc: # all
Signed-of
d, caller);
> - WARN_ON_ONCE(!spin_is_locked(&devinfo->lock));
> + lockdep_assert_held(&devinfo->lock);
This change isn't equivalent.
lockdep_assert_held() will continue to emit warnings; ie., there is no
"once" functionality. Same for the other changes below.
Reg
On 05/02/2014 10:56 AM, Peter Hurley wrote:
Commit 6a20dbd6caa2358716136144bf524331d70b1e03,
"tty: Fix race condition between __tty_buffer_request_room and flush_to_ldisc"
correctly identifies an unsafe race condition between
__tty_buffer_request_room() and flush_to_ldisc(), where th
hich guarantees
the commit value read is the latest value written if the head is
advancing.
Reported-by: Manfred Schlaegl
Cc: # 3.12.x+
Signed-off-by: Peter Hurley
---
drivers/tty/tty_buffer.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/tty
On 03/13/2014 03:39 PM, Stefan Richter wrote:
On Mar 13 Peter Hurley wrote:
On 03/13/2014 09:59 AM, Stefan Richter wrote:
Incidentally, the mailman brought me a dual FW643-e2 card just yesterday
(IOI FWBX2-PCIE1XE220 alias Delock 89208). I will try to reproduce the
issue as time permits. I
On 03/13/2014 09:59 AM, Stefan Richter wrote:
On Mar 13 Peter Hurley wrote:
With patch applied, happened last night but I just noticed this am:
Mar 12 20:47:40 thor kernel: [2.516017] firewire_ohci :01:00.0: failed
to read phy reg 1
[...]
Mar 12 20:47:40 thor kernel: [2.516175
On 03/06/2014 02:39 PM, Stefan Richter wrote:
Since commit bd972688eb24
"firewire: ohci: Fix 'failed to read phy reg' on FW643 rev8",
there is a high chance that firewire-ohci fails to initialize LSI née
Agere controllers.
https://bugzilla.kernel.org/show_bug.cgi?id=65151
[ +cc linux-bluetooth ]
Hi Feng,
On 02/26/2014 12:11 AM, Feng Tang wrote:
Hi Peter,
2014-02-22 20:31 GMT+08:00 Peter Hurley :
The user-settable knob, low_latency, has been the source of
several BUG reports which stem from flush_to_ldisc() running
in interrupt context. Since 3.12, which added
if
it breaks stuff, we should revert it and add a second file just like
Peter suggested.
Or add sysfs entries for each console that exposes the device, so
that the underlying device is trivially discoverable, which is the
original problem.
Regards,
Peter Hurley
--
To unsubscribe from this list: s
wards
Cc: Stanislaw Gruszka
Cc: Hal Murray
Cc: Alan Cox
Cc: # 3.12.x+
Signed-off-by: Peter Hurley
---
drivers/tty/ipwireless/tty.c | 3 ---
drivers/tty/tty_buffer.c | 20
drivers/usb/gadget/u_serial.c | 4 ++--
include/linux/tty.h | 2 +-
4 files
ff on this one?
Without this patch systemd won't present a login console for s390.
I'd prefer fixing plymouth.
Not an option.
As I said before, the old interface should be left alone and
forked to present a new interface that systemd can use to
get what it expects.
Regards,
Peter Hurle
On 02/18/2014 10:30 AM, Tejun Heo wrote:
On Mon, Feb 17, 2014 at 09:29:34PM -0500, Peter Hurley wrote:
It never would have occurred to me that you could safely change the
function for a work item that is already scheduled or running.
Especially given that PREPARE_WORK() is just a simple
On 02/17/2014 08:43 PM, Ben Hutchings wrote:
On Sat, 2014-02-15 at 14:38 -0500, Peter Hurley wrote:
Since commit a2c1c57be8d9fd5b716113c8991d3d702eeacf77,
workqueue: consider work function when searching for busy work items
work items whose work functions are re-assigned are no longer
guarantee.
Cc: Stefan Richter
Cc:
Signed-off-by: Peter Hurley
---
Documentation/workqueue.txt | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/Documentation/workqueue.txt b/Documentation/workqueue.txt
index f81a65b..5b49491 100644
--- a/Documentation/workqueue.t
tty was stopped by soft flow control and is being
restarted
Reported-by: Mikulas Patocka
Cc: # 3.13.x
Signed-off-by: Peter Hurley
---
drivers/tty/n_tty.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index df6dda6
On 12/17/2013 12:30 PM, Greg Kroah-Hartman wrote:
On Mon, Dec 09, 2013 at 06:06:07PM -0500, Peter Hurley wrote:
On 12/07/2013 06:46 PM, Karl Dahlke wrote:
This may have appeared in 3.9.11 with the changes to tty.
Don't know; I just started running 3.12 from kernel.org.
Perhaps nobody s
[] get_signal_to_deliver+0x241/0x62f
[] do_signal+0x43/0x59d
[] ? __audit_syscall_exit+0x21a/0x2a8
[] ? lock_release_holdtime.part.8+0xf/0x16e
[] do_notify_resume+0x54/0x6c
[] int_signal+0x12/0x17
Reported-by: Sami Farin
Cc: # 3.12.x
Signed-off-by: Peter Hurley
---
drivers/tty/tty_ldsem.c | 16
should fix the 'newline output after the new prompt' problem.
Note however that the other output order you observe is correct:
you press enter, a newline is echoed to terminal which mixes
with program output, the program ends, and the cooked mode
shell outputs an extra prompt because it rea
the signal is sent before
the echo buffer is processed, the tty state may change before the
echo buffer is flushed.
Preserve observed order; flush echoes before signalling.
Cc: # 3.12.x
Signed-off-by: Peter Hurley
---
drivers/tty/n_tty.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion
When L_ECHONL is on, newlines are echoed regardless of the L_ECHO
state; if set, ensure accumulated echoes are flushed before finishing
the current input processing and before more output.
Cc: # 3.12.x
Reported-by: Jason Gunthorpe
Signed-off-by: Peter Hurley
---
drivers/tty/n_tty.c | 6
[1..4096].
Cc: # 3.12.x
Signed-off-by: Peter Hurley
---
drivers/tty/n_tty.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index 053ead2..0f74945 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -1998,7 +1998,10 @@ sta
Check the correct byte for the echo operation code byte.
Cc: # 3.12.x : c476f65 tty: incorrect test of
echo_buf() result for ECHO_OP_START
Cc: # 3.12.x
Signed-off-by: Peter Hurley
---
drivers/tty/n_tty.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/n_tty.c b/d
On 11/07/2013 01:59 PM, Peter Hurley wrote:
A departing reader must restart a flush_to_ldisc() worker _before_
the next reader enters the read loop; this is to avoid the new reader
concluding no more i/o is available and prematurely exiting, when the
old reader simply hasn't re-starte
not see
setsid() in the sources), I do not really care. but perhaps tcflush.c
should be updated.
I would agree with your analysis.
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
pline.
Cc: stable@vger.kernel.org # v3.10+
Reported-by: Oleg Nesterov
Signed-off-by: Peter Hurley
---
drivers/tty/tty_ioctl.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/tty/tty_ioctl.c b/drivers/tty/tty_ioctl.c
index 3500d41..088b4ca 100644
--- a/drivers/tty/tty_ioctl.c
+++ b/d
On 08/17/2013 07:51 AM, Toralf Förster wrote:
On 08/16/2013 11:45 PM, Peter Hurley wrote:
Seems unlikely. What is the last "good" 3.10?
Well, reverted your commit on top of 3.10.7 and tried there s2disk 8
times - 7 times it worked fine, the 8th were broken -
now I'm unsure i
y. What is the last "good" 3.10?
Can you attach your bisect log?
Regards,
Peter Hurley
commit e0896b461ff2761c7a36d223f33d4f6d52c7340f
Author: Peter Hurley
Date: Sat Jun 15 09:01:00 2013 -0400
tty: Reset itty for other pty
commit 64e377dcd7d75
has been released, issue a diagnostic and
abort the port destruction.
This will leak memory and may zombify the port, but should
otherwise keep the machine in runnable state.
Signed-off-by: Peter Hurley
---
drivers/tty/tty_port.c | 4
1 file changed, 4 insertions(+)
diff --git a/dri
tty_port to live at least
to ops->cleanup() (currently the default)
* allow tty_port lifetime to be completely independent of
a tty's lifetime
* remove ref-counting from tty_port
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe stable
ream.
Greg,
So many other serious error conditions are possible here, it seems
pointless to add this to 3.8-stable.
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo
On Tue, 2013-03-26 at 18:51 -0700, Andrew Morton wrote:
> On Tue, 26 Mar 2013 21:44:12 -0400 Peter Hurley
> wrote:
>
> > On Tue, 2013-03-26 at 12:43 -0700, a...@linux-foundation.org wrote:
> > > The patch titled
> > > Subject: revert "ipc: don't
;
> 877 msg_counter++;
> 878 }
> 879 tmp = tmp->next;
> 880 }
> 881 if (!IS_ERR(msg)) {
>
> the tmp->next deref goes
OOM -- which made no sense. Completely out of page blocks
larger than 32k on a 10gb machine with a bunch of emacs and terminal
windows open for 3 days, just doing code, build, code, build, code,
build?
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe stable&q
On Tue, 2013-02-12 at 12:35 -0800, Greg Kroah-Hartman wrote:
> 3.7-stable review patch. If anyone has any objections, please let me know.
FWIW, I never saw this on 3.7 but it happened 1st time on 3.8-rcX
I haven't tested this fix either.
Regards,
Peter Hurley
--
To unsubscribe from t
92 matches
Mail list logo
