1. 07 Jun, 2011 5 commits
    • 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
  2. 06 Jun, 2011 6 commits
  3. 04 Jun, 2011 17 commits
  4. 03 Jun, 2011 12 commits