Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 16 3月, 2013 1 次提交
  3. 12 3月, 2013 10 次提交
  5. 04 3月, 2013 1 次提交
  7. 28 2月, 2013 2 次提交
    • A
      more file_inode() open-coded instances · 6131ffaa
      由 Al Viro 提交于 
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      6131ffaa
    • L
      sysrq: don't depend on weak undefined arrays to have an address that compares as NULL · adf96e6f
      由 Linus Torvalds 提交于 
      When taking an address of an extern array, gcc quite naturally should be
able to say "an address of an object can never be NULL" and just
optimize away the test entirely.

However, the new alternate sysrq reset code (commit 154b7a48:
"Input: sysrq - allow specifying alternate reset sequence") did exactly
that, and declared platform_sysrq_reset_seq[] as a weak array, and
expecting that testing the address of the array would show whether it
actually got linked against something or not.

And that doesn't work with all gcc versions.  Clearly it works with
*some* versions of gcc, and maybe it's even supposed to work, but it
really is a very fragile concept.

So instead of testing the address of the weak variable, just create a
weak instance of that array that is empty.  If some platform then has a
real platform_sysrq_reset_seq[] that overrides our weak one, the linker
will switch to that one, and it all works without any run-time
conditionals at all.
Reported-by: NDave Airlie <airlied@gmail.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      adf96e6f
  9. 25 2月, 2013 1 次提交
    • N
      tty vt: fix character insertion overflow · a883b70d
      由 Nicolas Pitre 提交于 
      Commit 81732c3b ("tty vt: Fix line garbage in virtual console on
command line edition") broke insert_char() in multiple ways.  Then
commit b1a925f4 ("tty vt: Fix a regression in command line edition")
partially fixed it.  However, the buffer being moved is still too large
and overflowing beyond the end of the current line, corrupting existing
characters on the next line.

Example test case:

echo -e "abc\nde\x1b[A\x1b[4h \x1b[4l\x1b[B"

Expected result:

ab c
de

Current result:

ab c
 e

Needless to say that this is very annoying when inserting words in the
middle of paragraphs with certain text editors.
Signed-off-by: NNicolas Pitre <nico@linaro.org>
Cc: Jean-François Moine <moinejf@free.fr>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a883b70d
  11. 23 2月, 2013 1 次提交
  13. 20 2月, 2013 1 次提交
  15. 19 2月, 2013 2 次提交
  17. 16 2月, 2013 2 次提交
  19. 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
  21. 14 2月, 2013 7 次提交
  23. 09 2月, 2013 1 次提交
  25. 08 2月, 2013 3 次提交
  27. 07 2月, 2013 5 次提交
  29. 06 2月, 2013 2 次提交