Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 3 年多

通知 13
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 21 5月, 2013 1 次提交
  3. 19 2月, 2013 1 次提交
  5. 15 2月, 2013 1 次提交
    • T
      serial: imx: Fix recursive locking bug · 677fe555
      由 Thomas Gleixner 提交于 
      commit 9ec1882d (tty: serial: imx: console write routing is unsafe
on SMP) introduced a recursive locking bug in imx_console_write().

The callchain is:

imx_rxint()
  spin_lock_irqsave(&sport->port.lock,flags);
  ...
  uart_handle_sysrq_char();
    sysrq_function();
      printk();
        imx_console_write();
          spin_lock_irqsave(&sport->port.lock,flags); <--- DEAD

The bad news is that the kernel debugging facilities can dectect the
problem, but the printks never surface on the serial console for
obvious reasons.

There is a similar issue with oops_in_progress. If the kernel crashes
we really don't want to be stuck on the lock and unable to tell what
happened.

In general most UP originated drivers miss these checks and nobody
ever notices because CONFIG_PROVE_LOCKING seems to be still ignored by
a large number of developers.

The solution is to avoid locking in the sysrq case and trylock in the
oops_in_progress case.

This scheme is used in other drivers as well and it would be nice if
we could move this to a common place, so the usual copy/paste/modify
bugs can be avoided.

Now there is another issue with this scheme:

CPU0 	    	     	 CPU1
printk()
			 rxint()
			   sysrq_detection() -> sets port->sysrq
			 return from interrupt
  console_write()
     if (port->sysrq)
     	avoid locking

port->sysrq is reset with the next receive character. So as long as
the port->sysrq is not reset and this can take an endless amount of
time if after the break no futher receive character follows, all
console writes happen unlocked.

While the current writer is protected against other console writers by
the console sem, it's unprotected against open/close or other
operations which fiddle with the port. That's what the above mentioned
commit tried to solve.

That's an issue in all drivers which use that scheme and unfortunately
there is no easy workaround. The only solution is to have a separate
indicator port->sysrq_cpu. uart_handle_sysrq_char() then sets it to
smp_processor_id() before calling into handle_sysrq() and resets it to
-1 after that. Then change the locking check to:

     if (port->sysrq_cpu == smp_processor_id())
     	 locked = 0;
     else if (oops_in_progress)
         locked = spin_trylock_irqsave(port->lock, flags);
     else
  	 spin_lock_irqsave(port->lock, flags);

That would force all other cpus into the spin_lock path. Problem
solved, but that's way beyond the scope of this fix and really wants
to be implemented in a common function which calls the uart specific
write function to avoid another gazillion of hard to debug
copy/paste/modify bugs.
Reported-and-tested-by: NTim Sander <tim@krieglstein.org>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: stable <stable@vger.kernel.org>  # 3.6+
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      677fe555
  7. 07 2月, 2013 1 次提交
  9. 06 2月, 2013 1 次提交
  11. 18 1月, 2013 1 次提交
  13. 16 1月, 2013 7 次提交
  15. 22 9月, 2012 2 次提交
  17. 14 9月, 2012 1 次提交
  19. 06 9月, 2012 3 次提交
  21. 03 8月, 2012 1 次提交
  23. 01 7月, 2012 1 次提交
  25. 13 6月, 2012 1 次提交
  27. 11 5月, 2012 1 次提交
  29. 25 4月, 2012 1 次提交
    • S
      serial i.MX: do not depend on grouped clocks · 3a9465fa
      由 Sascha Hauer 提交于 
      the current i.MX clock support groups together unrelated clocks
to a single clock which is then used by the driver. This can't
be accomplished with the generic clock framework so we instead
request the individual clocks in the driver. For i.MX there are
generally three different clocks:

ipg: bus clock (needed to access registers)
ahb: dma relevant clock, sometimes referred to as hclk in the datasheet
per: bit clock, pixel clock

This patch changes the driver to request the individual clocks.
Currently all clk_get will get the same clock until the SoCs
are converted to the generic clock framework
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
      3a9465fa
  31. 01 2月, 2012 1 次提交
  33. 05 1月, 2012 6 次提交
  35. 27 11月, 2011 1 次提交
  37. 23 9月, 2011 1 次提交
  39. 25 8月, 2011 1 次提交
    • H
      serial/imx: support to handle break character · 019dc9ea
      由 Hui Wang 提交于 
      The imx UART hardware controller can identify BREAK character and the
imx_set_termios() can accept BRKINT set by users, but current existing
imx_rxint() can't pass BREAK character and TTY_BREAK to the tty layer
as other serial drivers do (8250.c omap_serial.c).

Here add code to handle BREAK character and pass it to tty layer.

To detect error occurrence, i use URXD_ERR to replace (URXD_OVRRUN |
URXD_FRMERR | ...) because any kind of error occurs, URXD_ERR will
always be set to 1.

I put the URXD_BRK to the first place to check since when BREAK error
occurs, not only URXD_BRK is set to 1, but also URXD_PRERR and
URXD_FRMERR are all set to 1. This arrangement can filter out fake
parity and frame errors when BREAK error occurs.
Signed-off-by: NHui Wang <jason77.wang@gmail.com>
Acked-by: NSascha Hauer <s.hauer@pengutronix.de>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      019dc9ea
  41. 04 8月, 2011 1 次提交
    • G
      dt: remove of_alias_get_id() reference · 9e191b22
      由 Grant Likely 提交于 
      of_alias_get_id() is broken and being reverted.  Remove the reference
to it and replace with a single incrementing id number.

There is no risk of regression here on the imx driver since the imx
change to use of_alias_get_id() is commit 22698aa2, "serial/imx: add
device tree probe support" which is new for v3.1, and it won't get
used unless CONFIG_OF is enabled and the board is booted using a
device tree.  A single incrementing integer is sufficient for now.
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
      9e191b22
  43. 27 7月, 2011 2 次提交
  45. 10 6月, 2011 1 次提交
  47. 20 4月, 2011 2 次提交