1. 23 Mar, 2012 15 commits
  2. 22 Mar, 2012 1 commit
  3. 20 Mar, 2012 1 commit
  4. 12 Mar, 2012 1 commit
  5. 08 Mar, 2012 1 commit
  6. 06 Mar, 2012 1 commit
    • Jan Beulich's avatar
      vsprintf: make %pV handling compatible with kasprintf() · 5756b76e
      Jan Beulich authored
      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: default avatarJan Beulich <jbeulich@suse.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5756b76e
  7. 05 Mar, 2012 1 commit
  8. 21 Feb, 2012 2 commits
  9. 11 Feb, 2012 1 commit
  10. 09 Feb, 2012 1 commit
    • David Howells's avatar
      Reduce the number of expensive division instructions done by _parse_integer() · 690d137f
      David Howells authored
      _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: default avatarDavid 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: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      690d137f
  11. 01 Feb, 2012 13 commits
  12. 31 Jan, 2012 1 commit
  13. 26 Jan, 2012 1 commit
    • Prarit Bhargava's avatar
      bugs, x86: Fix printk levels for panic, softlockups and stack dumps · b0f4c4b3
      Prarit Bhargava authored
      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: default avatarPrarit 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: default avatarIngo Molnar <mingo@elte.hu>
      b0f4c4b3