Skip to content

L
linux-davinci
Switch branch/tag
  1. 10 Dec, 2009 4 commits
    • Thomas Gleixner's avatar
      sys: Fix missing rcu protection for __task_cred() access · d4581a23
      Thomas Gleixner authored 
      commit c69e8d9c (CRED: Use RCU to access another task's creds and to
release a task's own creds) added non rcu_read_lock() protected access
to task creds of the target task in set_prio_one().

The comment above the function says:
 * - the caller must hold the RCU read lock

The calling code in sys_setpriority does read_lock(&tasklist_lock) but
not rcu_read_lock(). This works only when CONFIG_TREE_PREEMPT_RCU=n.
With CONFIG_TREE_PREEMPT_RCU=y the rcu_callbacks can run in the tick
interrupt when they see no read side critical section.

There is another instance of __task_cred() in sys_setpriority() itself
which is equally unprotected.

Wrap the whole code section into a rcu read side critical section to
fix this quick and dirty.

Will be revisited in course of the read_lock(&tasklist_lock) -> rcu
crusade.

Oleg noted further:

This also fixes another bug here. find_task_by_vpid() is not safe
without rcu_read_lock(). I do not mean it is not safe to use the
result, just find_pid_ns() by itself is not safe.

Usually tasklist gives enough protection, but if copy_process() fails
it calls free_pid() lockless and does call_rcu(delayed_put_pid().
This means, without rcu lock find_pid_ns() can't scan the hash table
safely.
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
LKML-Reference: <20091210004703.029784964@linutronix.de>
Acked-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      d4581a23
    • Thomas Gleixner's avatar
      signals: Fix more rcu assumptions · 7cf7db8d
      Thomas Gleixner authored 
      1) Remove the misleading comment in __sigqueue_alloc() which claims
   that holding a spinlock is equivalent to rcu_read_lock().

2) Add a rcu_read_lock/unlock around the __task_cred() access
   in __sigqueue_alloc()

This needs to be revisited to remove the remaining users of
read_lock(&tasklist_lock) but that's outside the scope of this patch.
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
LKML-Reference: <20091210004703.269843657@linutronix.de>
      7cf7db8d
    • Thomas Gleixner's avatar
      signal: Fix racy access to __task_cred in kill_pid_info_as_uid() · 14d8c9f3
      Thomas Gleixner authored 
      kill_pid_info_as_uid() accesses __task_cred() without being in a RCU
read side critical section. tasklist_lock is not protecting that when
CONFIG_TREE_PREEMPT_RCU=y.

Convert the whole tasklist_lock section to rcu and use
lock_task_sighand to prevent the exit race.
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
LKML-Reference: <20091210004703.232302055@linutronix.de>
Acked-by: default avatarOleg Nesterov <oleg@redhat.com>
      14d8c9f3
    • Luck, Tony's avatar
      lockdep: Avoid out of bounds array reference in save_trace() · ea5b41f9
      Luck, Tony authored 
      ia64 found this the hard way (because we currently have a stub
for save_stack_trace() that does nothing). But it would be a
good idea to  be cautious in case a real save_stack_trace()
bailed out with an error before it set trace->nr_entries.
Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
Acked-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
Cc: luming.yu@intel.com
LKML-Reference: <4b2024d085302c2a2@agluck-desktop.sc.intel.com>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      ea5b41f9
  3. 08 Dec, 2009 1 commit
  5. 06 Dec, 2009 2 commits
  7. 05 Dec, 2009 25 commits
  9. 03 Dec, 2009 8 commits
    • Ingo Molnar's avatar
      Merge branch 'perf/probes' into perf/core · d103d01e
      Ingo Molnar authored 
      Merge reason: add these fixes to 'perf probe'.
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      d103d01e
    • Ingo Molnar's avatar
      Merge branch 'perf/mce' into perf/core · 26fb20d0
      Ingo Molnar authored 
      Merge reason: It's ready for v2.6.33.
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      26fb20d0
    • Ingo Molnar's avatar
      Merge branch 'perf/scripting' into perf/core · 23ba90e3
      Ingo Molnar authored 
      Merge reason: it's ready for v2.6.33.
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      23ba90e3
    • Mikael Pettersson's avatar
      x86, apic: Enable lapic nmi watchdog on AMD Family 11h · 7d1849af
      Mikael Pettersson authored 
      The x86 lapic nmi watchdog does not recognize AMD Family 11h,
resulting in:

  NMI watchdog: CPU not supported

As far as I can see from available documentation (the BKDM),
family 11h looks identical to family 10h as far as the PMU
is concerned.

Extending the check to accept family 11h results in:

  Testing NMI watchdog ... OK.

I've been running with this change on a Turion X2 Ultra ZM-82
laptop for a couple of weeks now without problems.
Signed-off-by: default avatarMikael Pettersson <mikpe@it.uu.se>
Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
Cc: Joerg Roedel <joerg.roedel@amd.com>
Cc: <stable@kernel.org>
LKML-Reference: <19223.53436.931768.278021@pilspetsen.it.uu.se>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      7d1849af
    • Steven Whitehouse's avatar
      GFS2: Fix glock refcount issues · 26bb7505
      Steven Whitehouse authored 
      This patch fixes some ref counting issues. Firstly by moving
the point at which we drop the ref count after a dlm lock
operation has completed we ensure that we never call
gfs2_glock_hold() on a lock with a zero ref count.

Secondly, by using atomic_dec_and_lock() in gfs2_glock_put()
we ensure that at no time will a glock with zero ref count
appear on the lru_list. That means that we can remove the
check for this in our shrinker (which was racy).
Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
      26bb7505
    • Wu Fengguang's avatar
      writeback: remove unused nonblocking and congestion checks (gfs2) · c29cd900
      Wu Fengguang authored 
      No one is calling wb_writeback and write_cache_pages with
wbc.nonblocking=1 any more. And lumpy pageout will want to do
nonblocking writeback without the congestion wait.
Signed-off-by: default avatarWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
      c29cd900
    • Benjamin Marzinski's avatar
      GFS2: drop rindex glock to refresh rindex list · 9ae3c6de
      Benjamin Marzinski authored 
      When a gfs2 filesystem is grown, it needs to rebuild the rindex list to be able
to use the new space.  gfs2 does this when the rindex is marked not uptodate,
which happens when the rindex glock is dropped.  However, on a single node
setup, there is never any reason to drop the rindex glock, so gfs2 never
invalidates the the rindex. This patch makes gfs2 automatically drop the
rindex glock after filesystem grows, so it can refresh the rindex list.
Signed-off-by: default avatarBenjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
      9ae3c6de
    • Steven Whitehouse's avatar
      GFS2: Tag all metadata with jid · 0ab7d13f
      Steven Whitehouse authored 
      There are two spare field in the header common to all GFS2
metadata. One is just the right size to fit a journal id
in it, and this patch updates the journal code so that each
time a metadata block is modified, we tag it with the journal
id of the node which is performing the modification.

The reason for this is that it should make it much easier to
debug issues which arise if we can tell which node was the
last to modify a particular metadata block.

Since the field is updated before the block is written into
the journal, each journal should only contain metadata which
is tagged with its own journal id. The one exception to this
is the journal header block, which might have a different node's
id in it, if that journal was recovered by another node in the
cluster.

Thus each journal will contain a record of which nodes recovered
it, via the journal header.

The other field in the metadata header could potentially be
used to hold information about what kind of operation was
performed, but for the time being we just zero it on each
transaction so that if we use it for that in future, we'll
know that the information (where it exists) is reliable.

I did consider using the other field to hold the journal
sequence number, however since in GFS2's journaling we write
the modified data into the journal and not the original
data, this gives no information as to what action caused the
modification, so I think we can probably come up with a better
use for those 64 bits in the future.
Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
      0ab7d13f