Skip to content

L
linux
Switch branch/tag
  1. 16 Jun, 2011 3 commits
  3. 07 Jun, 2011 6 commits
    • Jiri Slaby's avatar
      TTY: ntty, add one more sanity check · 28726286
      Jiri Slaby authored 
      With the previous patch, we fixed another bug where read_buf was freed
while we still was in n_tty_read. We currently check whether read_buf
is NULL at the start of the function. Add one more check after we wake
up from waiting for input.
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      28726286
    • Jiri Slaby's avatar
      TTY: ldisc, do not close until there are readers · 92f6fa09
      Jiri Slaby authored 
      We restored tty_ldisc_wait_idle in 100eeae2 (TTY: restore
tty_ldisc_wait_idle). We used it in the ldisc changing path to fix the
case where there are tasks in n_tty_read waiting for data and somebody
tries to change ldisc.

Similar to the case above, there may be also tasks waiting in
n_tty_read while hangup is performed. As 65b77046 (tty-ldisc: turn
ldisc user count into a proper refcount) removed the wait-until-idle
from all paths, hangup path won't wait for them to disappear either
now. So add it back even to the hangup path.

There is a difference, we need uninterruptible sleep as there is
obviously HUP signal pending. So tty_ldisc_wait_idle now sleeps
without possibility to be interrupted. This is what original
tty_ldisc_wait_idle did. After the wait idle reintroduction
(100eeae2), we have had interruptible sleeps for the ldisc changing
path. But as there is a 5s timeout anyway, we don't allow it to be
interrupted from now on. It's not worth the added complexity of
deciding what kind of sleep we want.

Before 65b77046 tty_ldisc_release was called also from
tty_ldisc_release. It is called from tty_release, so I don't think we
need to restore that one.

This is nicely reproducible after constifying the timing when
drivers/tty/n_tty.c is patched as follows ("TTY: ntty, add one more
sanity check" patch is needed to actually see it explode):
%% -1548,6 +1549,7 @@ static int n_tty_open(struct tty_struct *tty)

        /* These are ugly. Currently a malloc failure here can panic */
        if (!tty->read_buf) {
+               msleep(100);
                tty->read_buf = kzalloc(N_TTY_BUF_SIZE, GFP_KERNEL);
                if (!tty->read_buf)
                        return -ENOMEM;
%% -1785,6 +1788,7 @@ do_it_again:
                                break;
                        }
                        timeout = schedule_timeout(timeout);
+                       msleep(20);
                        continue;
                }
                __set_current_state(TASK_RUNNING);
===== With a process: =====
    while (1) {
        int fd = open(argv[1], O_RDWR);
        read(fd, buf, sizeof(buf));
        close(fd);
    }
===== and its child: =====
        setsid();
        while (1) {
                int fd = open(tty, O_RDWR|O_NOCTTY);
                ioctl(fd, TIOCSCTTY, 1);
                vhangup();
                close(fd);
                usleep(100 * (10 + random() % 1000));
        }
===== EOF =====

References: https://bugzilla.novell.com/show_bug.cgi?id=693374
References: https://bugzilla.novell.com/show_bug.cgi?id=694509Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: stable <stable@kernel.org> [32, 33, 34, 39]
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      92f6fa09
    • leitao@linux.vnet.ibm.com's avatar
      8250: Fix capabilities when changing the port type · cb01ece3
      leitao@linux.vnet.ibm.com authored 
      When changing the port type, the capabilities flags should be changed
also, otherwise the capabilities will not correspond to the port type,
which make set_sleep() crash on rmmod.

This patch just assign the correct capabilites when the port changes.
Signed-off-by: default avatarBreno Leitao <leitao@linux.vnet.ibm.com>
CC: Michael Reed <mreed@linux.vnet.ibm.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      cb01ece3
    • Alan Cox's avatar
      8250_pci: Fix missing const from merges · 1798ca13
      Alan Cox authored 
      Signed-off-by: default avatarAlan Cox <alan@linux.intel.com>
Signed-off-by: default avatarAntony Pavlov <antony@niisi.msk.ru>
Signed-off-by: default avatarBorislav Petkov <bp@alien8.de>
Signed-off-by: default avatarVasily Averin <vvs@sw.ru>
Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      1798ca13
    • Boojin Kim's avatar
      ARM: SAMSUNG: serial: Fix on handling of one clock source for UART · 470f2297
      Boojin Kim authored 
      This patch fixes the way of comparison for handling of two or more
clock sources for UART.

For example, if just only one clock source is defined even though
there are two clock sources for UART, the serial driver does not
set proper clock up. Of course, it is problem.

So this patch changes the condition of comparison to avoid useless
setup clock and adds a flag 'NO_NEED_CHECK_CLKSRC' which means
selection of source clock is not required.

In addition, since the Exynos4210 has only one clock source for UART
this patch adds the flag into its common_init_uarts().
Signed-off-by: default avatarBoojin Kim <boojin.kim@samsung.com>
Signed-off-by: default avatarKukjin Kim <kgene.kim@samsung.com>
Cc: stable <stable@kernel.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      470f2297
    • Lennart Sorensen's avatar
      serial: ioremap warning fix for jsm driver. · af99d6f0
      Lennart Sorensen authored 
      I saw a warning about ioremap from the jsm driver on a system which
looked like this:

resource map sanity check conflict: 0xe0200800 0xe02017ff 0xe0200800 0xe0200fff 0000:01:08.0

Turns out the warning is valid.  The jsm driver has been asking to ioremap
0x1000 forever, but in fact only 8 port chips have 0x1000 bytes of memory.
4 port chips have 0x800 and 2 port chips have 0x400 according to the
data sheet.  It makes more sense to map the size of the region rather
than a hard coded value.  If you happen to have the region legitimately
mapped to a base address that is not 4K aligned, ioremap complains
otherwise.
Signed-off-by: default avatarLen Sorensen <lsorense@csclub.uwaterloo.ca>
Acked-by: default avatarAlan Cox <alan@linux.intel.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      af99d6f0
  5. 06 Jun, 2011 6 commits
  7. 04 Jun, 2011 17 commits
  9. 03 Jun, 2011 8 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7