1. 24 3月, 2012 15 次提交
  2. 22 3月, 2012 1 次提交
  3. 20 3月, 2012 1 次提交
  4. 12 3月, 2012 1 次提交
  5. 09 3月, 2012 1 次提交
  6. 07 3月, 2012 1 次提交
    • J
      vsprintf: make %pV handling compatible with kasprintf() · 5756b76e
      Jan Beulich 提交于
      kasprintf() (and potentially other functions that I didn't run across so
      far) want to evaluate argument lists twice.  Caring to do so for the
      primary list is obviously their job, but they can't reasonably be
      expected to check the format string for instances of %pV, which however
      need special handling too: On architectures like x86-64 (as opposed to
      e.g.  ix86), using the same argument list twice doesn't produce the
      expected results, as an internally managed cursor gets updated during
      the first run.
      
      Fix the problem by always acting on a copy of the original list when
      handling %pV.
      Signed-off-by: NJan Beulich <jbeulich@suse.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5756b76e
  7. 06 3月, 2012 1 次提交
  8. 22 2月, 2012 2 次提交
  9. 11 2月, 2012 1 次提交
  10. 10 2月, 2012 1 次提交
    • D
      Reduce the number of expensive division instructions done by _parse_integer() · 690d137f
      David Howells 提交于
      _parse_integer() does one or two division instructions (which are slow)
      per digit parsed to perform the overflow check.
      
      Furthermore, these are particularly expensive examples of division
      instruction as the number of clock cycles required to complete them may
      go up with the position of the most significant set bit in the dividend:
      
      	if (*res > div_u64(ULLONG_MAX - val, base))
      
      which is as maximal as possible.
      
      Worse, on 32-bit arches, more than one of these division instructions
      may be required per digit.
      
      So, assuming we don't support a base of more than 16, skip the check if the
      top nibble of the result is not set at this point.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      [ Changed it to not dereference the pointer all the time - even if the
        compiler can and does optimize it away, the code just looks cleaner.
        And edited the top nybble test slightly to make the code generated on
        x86-64 better in the loop - test against a hoisted constant instead of
        shifting and testing the result ]
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      690d137f
  11. 02 2月, 2012 2 次提交
  12. 01 2月, 2012 12 次提交
  13. 27 1月, 2012 1 次提交
    • P
      bugs, x86: Fix printk levels for panic, softlockups and stack dumps · b0f4c4b3
      Prarit Bhargava 提交于
      rsyslog will display KERN_EMERG messages on a connected
      terminal.  However, these messages are useless/undecipherable
      for a general user.
      
      For example, after a softlockup we get:
      
       Message from syslogd@intel-s3e37-04 at Jan 25 14:18:06 ...
       kernel:Stack:
      
       Message from syslogd@intel-s3e37-04 at Jan 25 14:18:06 ...
       kernel:Call Trace:
      
       Message from syslogd@intel-s3e37-04 at Jan 25 14:18:06 ...
       kernel:Code: ff ff a8 08 75 25 31 d2 48 8d 86 38 e0 ff ff 48 89
       d1 0f 01 c8 0f ae f0 48 8b 86 38 e0 ff ff a8 08 75 08 b1 01 4c 89 e0 0f 01 c9 <e8> ea 69 dd ff 4c 29 e8 48 89 c7 e8 0f bc da ff 49 89 c4 49 89
      
      This happens because the printk levels for these messages are
      incorrect. Only an informational message should be displayed on
      a terminal.
      
      I modified the printk levels for various messages in the kernel
      and tested the output by using the drivers/misc/lkdtm.c kernel
      modules (ie, softlockups, panics, hard lockups, etc.) and
      confirmed that the console output was still the same and that
      the output to the terminals was correct.
      
      For example, in the case of a softlockup we now see the much
      more informative:
      
       Message from syslogd@intel-s3e37-04 at Jan 25 10:18:06 ...
       BUG: soft lockup - CPU4 stuck for 60s!
      
      instead of the above confusing messages.
      
      AFAICT, the messages no longer have to be KERN_EMERG.  In the
      most important case of a panic we set console_verbose().  As for
      the other less severe cases the correct data is output to the
      console and /var/log/messages.
      
      Successfully tested by me using the drivers/misc/lkdtm.c module.
      Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
      Cc: dzickus@redhat.com
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Link: http://lkml.kernel.org/r/1327586134-11926-1-git-send-email-prarit@redhat.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
      b0f4c4b3