Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 17 6月, 2011 4 次提交
  3. 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
  5. 04 6月, 2011 1 次提交
    • L
      Revert "tty: make receive_buf() return the amout of bytes received" · 55db4c64
      由 Linus Torvalds 提交于 
      This reverts commit b1c43f82.

It was broken in so many ways, and results in random odd pty issues.

It re-introduced the buggy schedule_work() in flush_to_ldisc() that can
cause endless work-loops (see commit a5660b41: "tty: fix endless
work loop when the buffer fills up").

It also used an "unsigned int" return value fo the ->receive_buf()
function, but then made multiple functions return a negative error code,
and didn't actually check for the error in the caller.

And it didn't actually work at all.  BenH bisected down odd tty behavior
to it:
  "It looks like the patch is causing some major malfunctions of the X
   server for me, possibly related to PTYs.  For example, cat'ing a
   large file in a gnome terminal hangs the kernel for -minutes- in a
   loop of what looks like flush_to_ldisc/workqueue code, (some ftrace
   data in the quoted bits further down).

   ...

   Some more data: It -looks- like what happens is that the
   flush_to_ldisc work queue entry constantly re-queues itself (because
   the PTY is full ?) and the workqueue thread will basically loop
   forver calling it without ever scheduling, thus starving the consumer
   process that could have emptied the PTY."

which is pretty much exactly the problem we fixed in a5660b41.

Milton Miller pointed out the 'unsigned int' issue.
Reported-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Reported-by: NMilton Miller <miltonm@bga.com>
Cc: Stefan Bigler <stefan.bigler@keymile.com>
Cc: Toby Gray <toby.gray@realvnc.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      55db4c64
  7. 03 6月, 2011 1 次提交
  9. 27 5月, 2011 1 次提交
  11. 25 5月, 2011 3 次提交
    • A
      drivers/tty/serial/pch_uart.c needs slab.h · 023bc8e7
      由 Andrew Morton 提交于 
      alpha allmodconfig:

  drivers/tty/serial/pch_uart.c: In function 'dma_handle_tx':
  drivers/tty/serial/pch_uart.c:873: error: implicit declaration of function 'kzalloc'
  drivers/tty/serial/pch_uart.c:873: warning: assignment makes pointer from integer without a cast
  drivers/tty/serial/pch_uart.c: In function 'pch_uart_init_port':
  drivers/tty/serial/pch_uart.c:1403: warning: assignment makes pointer from integer without a cast

Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      023bc8e7
    • D
      arch, mm: filter disallowed nodes from arch specific show_mem functions · 7bf02ea2
      由 David Rientjes 提交于 
      Architectures that implement their own show_mem() function did not pass
the filter argument to show_free_areas() to appropriately avoid emitting
the state of nodes that are disallowed in the current context.  This patch
now passes the filter argument to show_free_areas() so those nodes are now
avoided.

This patch also removes the show_free_areas() wrapper around
__show_free_areas() and converts existing callers to pass an empty filter.

ia64 emits additional information for each node, so skip_free_areas_zone()
must be made global to filter disallowed nodes and it is converted to use
a nid argument rather than a zone for this use case.
Signed-off-by: NDavid Rientjes <rientjes@google.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Kyle McMartin <kyle@mcmartin.ca>
Cc: Helge Deller <deller@gmx.de>
Cc: James Bottomley <jejb@parisc-linux.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7bf02ea2
    • J
      atmel_serial: keep the platform_device unchanged · 2b348e2f
      由 Jean-Christophe PLAGNIOL-VILLARD 提交于 
      specify the port num via platform_data this will allow to match the clock
with the plaform_dev staticaly
Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: NAlan Cox <alan@linux.intel.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Patrice Vilchez <patrice.vilchez@atmel.com>
Cc: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
      2b348e2f
  13. 23 5月, 2011 3 次提交
  15. 20 5月, 2011 3 次提交
  17. 19 5月, 2011 2 次提交
  19. 14 5月, 2011 1 次提交
    • J
      n_tracerouter and n_tracesink ldisc additions. · ee4f6b4b
      由 J Freyensee 提交于 
      The n_tracerouter and n_tracesink line discpline drivers use the
Linux tty line discpline framework to route trace data coming
from a tty port (say UART for example) to the trace sink line
discipline driver and to another tty port(say USB).  Those
these two line discipline drivers can be used together,
independently from pti.c, they are part of the original
implementation solution of the MIPI P1149.7, compact JTAG, PTI
solution for Intel mobile platforms starting with the
Medfield platform.
Signed-off-by: NJ Freyensee <james_p_freyensee@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      ee4f6b4b
  21. 13 5月, 2011 1 次提交
  23. 12 5月, 2011 1 次提交
    • S
      8250_pci: Add support for the Digi/IBM PCIe 2-port Adapter · aa273ae5
      由 Scott Kilau 提交于 
      Add support to the 8250 PCI serial driver for the Digi/IBM PCIe 2-port Async EIA-232 Adapter.

Oxford Semiconductor produces a 2/4/8 port UART (OXPCIe952/OXPCIe954/OXPCIe958) chip
called the Tornado, that can be used to create a very simple serial board product.
The kernel sources currently have just 2 vendors using this chip, which is Oxford and Mainpipe.
This new Digi/IBM serial product now uses it as well.

Rather than create a long running comment of vendors using the chip, the one changed comment
in the patch below now just lists "For Oxford Semiconductor Tornado based devices" to be a
more generic comment for all vendors that end up using the Oxford Tornado chip.

Cc: Michael Reed <mreed10@us.ibm.com>
Signed-off-by: NScott Kilau <scottk@digi.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      aa273ae5
  25. 11 5月, 2011 1 次提交
  27. 10 5月, 2011 1 次提交
  29. 06 5月, 2011 1 次提交
  31. 04 5月, 2011 1 次提交
  33. 30 4月, 2011 2 次提交
  35. 26 4月, 2011 7 次提交