public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Andrew Morton <akpm@osdl.org>
Cc: mingo@elte.hu, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] protect remove_proc_entry
Date: Tue, 10 Jan 2006 08:26:30 -0500	[thread overview]
Message-ID: <1136899590.6197.30.camel@localhost.localdomain> (raw)
In-Reply-To: <1136834210.6197.10.camel@localhost.localdomain>

Andrew, here's a better explanation of the patch as well as my
Signed-off.

Description:

It has been discovered that the remove_proc_entry has a race in the
removing of entries in the proc file system that are siblings.  There's
no protection around the traversing and removing of elements that belong
in the same subdirectory.

This subdirectory list is protected in other areas by the BKL.  So the
BKL was at first used to protect this area too, but unfortunately,
remove_proc_entry may be called with spinlocks held.  The BKL may
schedule, so this was not a solution.

The final solution was to add a new global spin lock to protect this
list, called proc_subdir_lock.  This lock now protects the list in
remove_proc_entry, and I also went around looking for other areas that
this list is modified and added this protection there too.  Care must be
taken since these locations call several functions that may also
schedule.

Since I don't see any location that these functions that modify the
subdirectory list are called by interrupts, the irqsave/restore versions
of the spin lock was _not_ used.

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>


-- Steve



      parent reply	other threads:[~2006-01-10 13:27 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-30 20:04 [Question] race condition with remove_proc_entry Steven Rostedt
2005-12-30 21:28 ` [PATCH] protect remove_proc_entry Steven Rostedt
2005-12-30 21:34   ` Daniel Walker
2005-12-30 21:55     ` Steven Rostedt
2005-12-30 21:55   ` Mitchell Blank Jr
2005-12-30 22:09     ` Steven Rostedt
2005-12-30 22:18       ` Steven Rostedt
2006-01-04  9:21         ` Andrew Morton
2006-01-04 12:18           ` Steven Rostedt
2006-01-05  1:48             ` Mitchell Blank Jr
2006-01-07 11:25       ` Andrew Morton
2005-12-30 22:11     ` Steven Rostedt
2005-12-30 23:46   ` Andrew Morton
2005-12-31  6:58     ` Steven Rostedt
2005-12-31  8:34       ` Arjan van de Ven
2005-12-31  8:53     ` Kirill Korotaev
2006-01-04  9:36       ` Andrew Morton
2006-01-04 11:27         ` Kirill Korotaev
2006-01-02 13:02     ` Steven Rostedt
2006-01-07 11:36   ` Andrew Morton
2006-01-07 12:04     ` Steven Rostedt
2006-01-09 19:16     ` Steven Rostedt
2006-01-10  0:59       ` Steven Rostedt
2006-01-10  1:05         ` Ingo Molnar
2006-01-10 13:26       ` Steven Rostedt [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1136899590.6197.30.camel@localhost.localdomain \
    --to=rostedt@goodmis.org \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox