1. 17 6月, 2011 3 次提交
  2. 08 6月, 2011 6 次提交
    • J
      TTY: ntty, add one more sanity check · 28726286
      Jiri Slaby 提交于
      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: NJiri Slaby <jslaby@suse.cz>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      28726286
    • J
      TTY: ldisc, do not close until there are readers · 92f6fa09
      Jiri Slaby 提交于
      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: NJiri 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: NGreg Kroah-Hartman <gregkh@suse.de>
      92f6fa09
    • L
      8250: Fix capabilities when changing the port type · cb01ece3
      leitao@linux.vnet.ibm.com 提交于
      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: NBreno Leitao <leitao@linux.vnet.ibm.com>
      CC: Michael Reed <mreed@linux.vnet.ibm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      cb01ece3
    • A
      8250_pci: Fix missing const from merges · 1798ca13
      Alan Cox 提交于
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NAntony Pavlov <antony@niisi.msk.ru>
      Signed-off-by: NBorislav Petkov <bp@alien8.de>
      Signed-off-by: NVasily Averin <vvs@sw.ru>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      1798ca13
    • B
      ARM: SAMSUNG: serial: Fix on handling of one clock source for UART · 470f2297
      Boojin Kim 提交于
      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: NBoojin Kim <boojin.kim@samsung.com>
      Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      470f2297
    • L
      serial: ioremap warning fix for jsm driver. · af99d6f0
      Lennart Sorensen 提交于
      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: NLen Sorensen <lsorense@csclub.uwaterloo.ca>
      Acked-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      af99d6f0
  3. 06 6月, 2011 6 次提交
  4. 05 6月, 2011 4 次提交
  5. 04 6月, 2011 21 次提交