1. 28 Apr, 2008 6 commits
    • Harvey Harrison's avatar
      [PATCH 1/2] audit: move extern declarations to audit.h · c782f242
      Harvey Harrison authored
      Leave audit_sig_{uid|pid|sid} protected by #ifdef CONFIG_AUDITSYSCALL.
      
      Noticed by sparse:
      kernel/audit.c:73:6: warning: symbol 'audit_ever_enabled' was not declared. Should it be static?
      kernel/audit.c:100:8: warning: symbol 'audit_sig_uid' was not declared. Should it be static?
      kernel/audit.c:101:8: warning: symbol 'audit_sig_pid' was not declared. Should it be static?
      kernel/audit.c:102:6: warning: symbol 'audit_sig_sid' was not declared. Should it be static?
      kernel/audit.c:117:23: warning: symbol 'audit_ih' was not declared. Should it be static?
      kernel/auditfilter.c:78:18: warning: symbol 'audit_filter_list' was not declared. Should it be static?
      Signed-off-by: default avatarHarvey Harrison <harvey.harrison@gmail.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      c782f242
    • Eric Paris's avatar
      Audit: standardize string audit interfaces · b556f8ad
      Eric Paris authored
      This patch standardized the string auditing interfaces.  No userspace
      changes will be visible and this is all just cleanup and consistancy
      work.  We have the following string audit interfaces to use:
      
      void audit_log_n_hex(struct audit_buffer *ab, const unsigned char *buf, size_t len);
      
      void audit_log_n_string(struct audit_buffer *ab, const char *buf, size_t n);
      void audit_log_string(struct audit_buffer *ab, const char *buf);
      
      void audit_log_n_untrustedstring(struct audit_buffer *ab, const char *string, size_t n);
      void audit_log_untrustedstring(struct audit_buffer *ab, const char *string);
      
      This may be the first step to possibly fixing some of the issues that
      people have with the string output from the kernel audit system.  But we
      still don't have an agreed upon solution to that problem.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      b556f8ad
    • Eric Paris's avatar
      Audit: stop deadlock from signals under load · f09ac9db
      Eric Paris authored
      A deadlock is possible between kauditd and auditd under load if auditd
      receives a signal.  When auditd receives a signal it sends a netlink
      message to the kernel asking for information about the sender of the
      signal.  In that same context the audit system will attempt to send a
      netlink message back to the userspace auditd.  If kauditd has already
      filled the socket buffer (see netlink_attachskb()) auditd will now put
      itself to sleep waiting for room to send the message.  Since auditd is
      responsible for draining that socket we have a deadlock.  The fix, since
      the response from the kernel does not need to be synchronous is to send
      the signal information back to auditd in a separate thread.  And thus
      auditd can continue to drain the audit queue normally.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      f09ac9db
    • Eric Paris's avatar
      Audit: save audit_backlog_limit audit messages in case auditd comes back · f3d357b0
      Eric Paris authored
      This patch causes the kernel audit subsystem to store up to
      audit_backlog_limit messages for use by auditd if it ever appears
      sometime in the future in userspace.  This is useful to collect audit
      messages during bootup and even when auditd is stopped.  This is NOT a
      reliable mechanism, it does not ever call audit_panic, nor should it.
      audit_log_lost()/audit_panic() are called during the normal delivery
      mechanism.  The messages are still sent to printk/syslog as usual and if
      too many messages appear to be queued they will be silently discarded.
      
      I liked doing it by default, but this patch only uses the queue in
      question if it was booted with audit=1 or if the kernel was built
      enabling audit by default.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      f3d357b0
    • Eric Paris's avatar
      Audit: collect sessionid in netlink messages · 2532386f
      Eric Paris authored
      Previously I added sessionid output to all audit messages where it was
      available but we still didn't know the sessionid of the sender of
      netlink messages.  This patch adds that information to netlink messages
      so we can audit who sent netlink messages.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      2532386f
    • Eric Paris's avatar
      Audit: end printk with newline · 436c405c
      Eric Paris authored
      A couple of audit printk statements did not have a newline.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      436c405c
  2. 27 Apr, 2008 1 commit
    • Carsten Otte's avatar
      s390: KVM preparation: provide hook to enable pgstes in user pagetable · 402b0862
      Carsten Otte authored
      The SIE instruction on s390 uses the 2nd half of the page table page to
      virtualize the storage keys of a guest. This patch offers the s390_enable_sie
      function, which reorganizes the page tables of a single-threaded process to
      reserve space in the page table:
      s390_enable_sie makes sure that the process is single threaded and then uses
      dup_mm to create a new mm with reorganized page tables. The old mm is freed
      and the process has now a page status extended field after every page table.
      
      Code that wants to exploit pgstes should SELECT CONFIG_PGSTE.
      
      This patch has a small common code hit, namely making dup_mm non-static.
      
      Edit (Carsten): I've modified Martin's patch, following Jeremy Fitzhardinge's
      review feedback. Now we do have the prototype for dup_mm in
      include/linux/sched.h. Following Martin's suggestion, s390_enable_sie() does now
      call task_lock() to prevent race against ptrace modification of mm_users.
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarCarsten Otte <cotte@de.ibm.com>
      Acked-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarAvi Kivity <avi@qumranet.com>
      402b0862
  3. 26 Apr, 2008 2 commits
  4. 25 Apr, 2008 4 commits
  5. 24 Apr, 2008 4 commits
    • Peter Zijlstra's avatar
      sched: fix share (re)distribution · 3f5087a2
      Peter Zijlstra authored
      fix __aggregate_redistribute_shares() related lockup reported by
      David S. Miller.
      
      The problem this code tries to solve is 'accurately' calculating the 'fair'
      share of the group weight for each cpu. The current code falls back to a global
      group rebalance in case the sched_domain's span it looks at has no shares, but
      does have tasks.
      
      The reason it gets stuck here, is because its inherently racy - if someone
      steals the last task after we compute the agg->rq_weight, but before we
      rebalance, we'll never get out of the loop.
      
      We could of course go fix that, but while looking at this issue I found that
      this 'fallback' wasn't nearly as rare as I'd hoped it to be. In fact its quite
      common - and given it walks the whole machine, thats very bad.
      
      The new approach is simple (why didn't I think of it before?), we set the
      aggregate shares to the full task group weight, and each larger sched domain
      that encounters an aggregate shares larger than the weight, clips it (it
      already re-distributes anyway).
      
      This nicely converges to the desired global picture where the sum of all
      shares equals the task group weight.
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      3f5087a2
    • Ingo Molnar's avatar
      softlockup: fix NOHZ wakeup · 126e01bf
      Ingo Molnar authored
      David Miller reported:
      
      |--------------->
      the following commit:
      
      | commit 27ec4407
      | Author: Ingo Molnar <mingo@elte.hu>
      | Date:   Thu Feb 28 21:00:21 2008 +0100
      |
      |     sched: make cpu_clock() globally synchronous
      |
      |     Alexey Zaytsev reported (and bisected) that the introduction of
      |     cpu_clock() in printk made the timestamps jump back and forth.
      |
      |     Make cpu_clock() more reliable while still keeping it fast when it's
      |     called frequently.
      |
      |     Signed-off-by: Ingo Molnar <mingo@elte.hu>
      
      causes watchdog triggers when a cpu exits NOHZ state when it has been
      there for >= the soft lockup threshold, for example here are some
      messages from a 128 cpu Niagara2 box:
      
      [  168.106406] BUG: soft lockup - CPU#11 stuck for 128s! [dd:3239]
      [  168.989592] BUG: soft lockup - CPU#21 stuck for 86s! [swapper:0]
      [  168.999587] BUG: soft lockup - CPU#29 stuck for 91s! [make:4511]
      [  168.999615] BUG: soft lockup - CPU#2 stuck for 85s! [swapper:0]
      [  169.020514] BUG: soft lockup - CPU#37 stuck for 91s! [swapper:0]
      [  169.020514] BUG: soft lockup - CPU#45 stuck for 91s! [sh:4515]
      [  169.020515] BUG: soft lockup - CPU#69 stuck for 92s! [swapper:0]
      [  169.020515] BUG: soft lockup - CPU#77 stuck for 92s! [swapper:0]
      [  169.020515] BUG: soft lockup - CPU#61 stuck for 92s! [swapper:0]
      [  169.112554] BUG: soft lockup - CPU#85 stuck for 92s! [swapper:0]
      [  169.112554] BUG: soft lockup - CPU#101 stuck for 92s! [swapper:0]
      [  169.112554] BUG: soft lockup - CPU#109 stuck for 92s! [swapper:0]
      [  169.112554] BUG: soft lockup - CPU#117 stuck for 92s! [swapper:0]
      [  169.171483] BUG: soft lockup - CPU#40 stuck for 80s! [dd:3239]
      [  169.331483] BUG: soft lockup - CPU#13 stuck for 86s! [swapper:0]
      [  169.351500] BUG: soft lockup - CPU#43 stuck for 101s! [dd:3239]
      [  169.531482] BUG: soft lockup - CPU#9 stuck for 129s! [mkdir:4565]
      [  169.595754] BUG: soft lockup - CPU#20 stuck for 93s! [swapper:0]
      [  169.626787] BUG: soft lockup - CPU#52 stuck for 93s! [swapper:0]
      [  169.626787] BUG: soft lockup - CPU#84 stuck for 92s! [swapper:0]
      [  169.636812] BUG: soft lockup - CPU#116 stuck for 94s! [swapper:0]
      
      It's simple enough to trigger this by doing a 10 minute sleep after a
      fresh bootup then starting a parallel kernel build.
      
      I suspect this might be reintroducing a problem we've had and fixed
      before, see the thread:
      
      http://marc.info/?l=linux-kernel&m=119546414004065&w=2
      <---------------|
      
      touch the softlockup watchdog when exiting NOHZ state - we are
      obviously not locked up.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      126e01bf
    • Mike Travis's avatar
      [PATCH] Build fix for CONFIG_NUMA=y && CONFIG_SMP=n · 03970f06
      Mike Travis authored
      Regression caused by 434d53b0Signed-off-by: default avatarMike Travis <travis@sgi.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      03970f06
    • Russ Anderson's avatar
      [IA64] fix bootmem regression on Altix · 472613b9
      Russ Anderson authored
      A recent change prevents SGI Altix from booting.
      This patch fixes the problem.
      
      The regresson was introduced in commit 434d53b0Signed-off-by: default avatarRuss Anderson <rja@sgi.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      472613b9
  6. 22 Apr, 2008 3 commits
  7. 21 Apr, 2008 6 commits
    • Roland McGrath's avatar
      ptrace: compat_ptrace_request siginfo · e16b2781
      Roland McGrath authored
      This adds support for PTRACE_GETSIGINFO and PTRACE_SETSIGINFO in
      compat_ptrace_request.  It relies on existing arch definitions for
      copy_siginfo_to_user32 and copy_siginfo_from_user32.
      
      On powerpc, this fixes a longstanding regression of 32-bit ptrace
      calls on 64-bit kernels vs native calls (64-bit calls or 32-bit
      kernels).  This can be seen in a 32-bit call using PTRACE_GETSIGINFO
      to examine e.g. siginfo_t.si_addr from a signal that sets it.
      (This was broken as of 2.6.24 and, I presume, many or all prior versions.)
      Signed-off-by: default avatarRoland McGrath <roland@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e16b2781
    • Pavel Machek's avatar
      trivial: small cleanups · f5264481
      Pavel Machek authored
      These are small cleanups all over the tree.
      
      Trivial style and comment changes to
        fs/select.c, kernel/signal.c, kernel/stop_machine.c & mm/pdflush.c
      Signed-off-by: default avatarPavel Machek <pavel@suse.cz>
      Signed-off-by: default avatarJesper Juhl <jesper.juhl@gmail.com>
      f5264481
    • Thomas Gleixner's avatar
      hrtimer: optimize the softirq time optimization · 259aae86
      Thomas Gleixner authored
      The previous optimization did not take the case into account where a
      clock provides its own softirq_get_time() function.
      
      Check for the availablitiy of the clock get time function first and
      then check if we need to retrieve the time for both clocks via
      hrtimer_softirq_gettime() to avoid a double evaluation of time in that
      case as well.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      259aae86
    • Dimitri Sivanich's avatar
      hrtimer: reduce calls to hrtimer_get_softirq_time() · 833883d9
      Dimitri Sivanich authored
      It seems that hrtimer_run_queues() is calling hrtimer_get_softirq_time() more
      often than it needs to.  This can cause frequent contention on systems with
      large numbers of processors/cores.
      
      With this patch, hrtimer_run_queues only calls hrtimer_get_softirq_time() if
      there is a pending timer in one of the hrtimer bases, and only once.
      
      This also combines hrtimer_run_queues() and the inline run_hrtimer_queue()
      into one function.
      
      [ tglx@linutronix.de: coding style ]
      Signed-off-by: default avatarDimitri Sivanich <sivanich@sgi.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      833883d9
    • Glauber Costa's avatar
      clockevents: fix typo in tick-broadcast.c · 833df317
      Glauber Costa authored
      braodcast -> broadcast
      Signed-off-by: default avatarGlauber Costa <gcosta@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      833df317
    • Ivan Kokshaysky's avatar
      PCI: clean up resource alignment management · 88452565
      Ivan Kokshaysky authored
      Done per Linus' request and suggestions. Linus has explained that
      better than I'll be able to explain:
      
      On Thu, Mar 27, 2008 at 10:12:10AM -0700, Linus Torvalds wrote:
      > Actually, before we go any further, there might be a less intrusive
      > alternative: add just a couple of flags to the resource flags field (we
      > still have something like 8 unused bits on 32-bit), and use those to
      > implement a generic "resource_alignment()" routine.
      >
      > Two flags would do it:
      >
      >  - IORESOURCE_SIZEALIGN: size indicates alignment (regular PCI device
      >    resources)
      >
      >  - IORESOURCE_STARTALIGN: start field is alignment (PCI bus resources
      >    during probing)
      >
      > and then the case of both flags zero (or both bits set) would actually be
      > "invalid", and we would also clear the IORESOURCE_STARTALIGN flag when we
      > actually allocate the resource (so that we don't use the "start" field as
      > alignment incorrectly when it no longer indicates alignment).
      >
      > That wouldn't be totally generic, but it would have the nice property of
      > automatically at least add sanity checking for that whole "res->start has
      > the odd meaning of 'alignment' during probing" and remove the need for a
      > new field, and it would allow us to have a generic "resource_alignment()"
      > routine that just gets a resource pointer.
      
      Besides, I removed IORESOURCE_BUS_HAS_VGA flag which was unused for ages.
      Signed-off-by: default avatarIvan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Gary Hade <garyhade@us.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      88452565
  8. 19 Apr, 2008 14 commits