* Re: smp_locks reference_discarded errors
From: Sam Ravnborg @ 2006-03-31 19:33 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Dave Jones, Andrew Morton, linux-kernel
In-Reply-To: <20060331190851.GB22677@stusta.de>
On Fri, Mar 31, 2006 at 09:08:51PM +0200, Adrian Bunk wrote:
> On Sun, Mar 26, 2006 at 06:10:55PM +0200, Sam Ravnborg wrote:
> > On Sun, Mar 26, 2006 at 10:40:42AM -0500, Dave Jones wrote:
> > >
> > > came out of a 'make buildcheck' a day or two ago (the following day,
> > > Sam nuked reference_discarded.pl in favour of it being done
> > > magically somewhere else (I've not looked into how its done now).
> > The check is part of modpost now. modpost is only used when building
> > modules but that holds true for most builds anyway therefore I did not
> > move it to a separate executable.
> >...
>
> This doesn't sound good.
>
> This means that we have no longer any tool that warns us about e.g.
> references from non-__exit code to __exit code [1]?
> [1] __exit, not __{dev,cpu,mem}exit
It does warn for this also. The test I have carried out has mostly been
on allmodconfig builds though. I assume you are worried for the case
when a module is built-in and the __exit section is discarded - or?
Sam
^ permalink raw reply
* Re: The sort algorithm is broken by the second rule, We need a way to pin these rules to the top.
From: Stephen Smalley @ 2006-03-31 19:32 UTC (permalink / raw)
To: Joshua Brindle
Cc: Ivan Gyurdiev, Christopher J. PeBenito, Daniel J Walsh, SE Linux
In-Reply-To: <442D809D.8050105@tresys.com>
On Fri, 2006-03-31 at 14:18 -0500, Joshua Brindle wrote:
> I think libsemanage should just put the .local file out for libselinux
> to read. There is no guarantee that none of the entries on .local won't
> be preceded by something in the normal file context if it is merged in
> libsemanage.
Last matching entry takes precedence, so as long as they are merged to
the end of file_contexts (as they presently are), the local entries will
always take precedence over any earlier matching entry.
> This is the same thing we do for file_contexts.homedirs so
> why not do it with .local? (Also, if we merge .local into the normal fc
> file then the .local can't override .homedirs)
.homedirs is a bit different in that it is generated via genhomedircon
from a policy-provided template. The last point is true - that does
yield a difference between ordering of entries added via semanage
fcontext -a vs. manually put into file_contexts.local.
However, changing libsemanage to install file_contexts.local instead of
merging it now is a behavioral change that could clobber an existing
file_contexts.local, so we'd have to be very careful about the "upgrade"
situation and we'd likely want to push that to FC5 ASAP so that users
there don't get used to being able to manually tinker with
file_contexts.local separately.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* [lm-sensors] Question on my mainboard
From: Dieter Jurzitza @ 2006-03-31 19:32 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <200603282150.16130.dieter.jurzitza@t-online.de>
Dear listmembers,
I tried to load the 83781d only according to your suggestions, and, yes,
everything is working like before. The driver detects the sensor chips and
reads all values from both chips. And, yes, the 83627 is read out even though
the corresponding module is not loaded. As readily mentioned, the deadlock
takes a while, so I'll wait and report what is happening.
This, however, leads me to the question why there is a different module for
the w83781d and the w83627hf at all - if the first can handle both?
Thanks again
take care
Dieter
--
-----------------------------------------------------------
|
\
/\_/\ |
| ~x~ |/-----\ /
\ /- \_/
^^__ _ / _ ____ /
<??__ \- \_/ | |/ | |
|| || _| _| _| _|
if you really want to see the pictures above - use some font
with constant spacing like courier! :-)
-----------------------------------------------------------
^ permalink raw reply
* Re: [spi-devel-general] Re: question on spi_bitbang
From: David Brownell @ 2006-03-31 19:32 UTC (permalink / raw)
To: spi-devel-general; +Cc: Kumar Gala, linux kernel mailing list
In-Reply-To: <29F33C89-519A-412B-9615-1944ED29FD9C@kernel.crashing.org>
On Friday 31 March 2006 11:07 am, Kumar Gala wrote:
> My controller is just a shift register that I can set the
> characteristics of (bit length for example, reverse data).
I've got a patch somewhere to enable LSB-first transfers in the API,
though without an implementation, if you're interested. I'll post it
as an RFC at some point.
> > The chipselect() call should only affect the chipselect signal and,
> > when you're activating a chip, its initial clock polarity. Though
> > if you're not using the latest from the MM tree, that's also your
> > hook for ensuring that the SPI mode is set up right.
>
> Why deal with just clock polarity and not clock phase as well in
> chipselect()?
You could, but the point is that you _must_ set the initial polarity
before setting the chipselect. Most SPI devices support modes 0 and 3,
and make the choice based on the clock polarity when chipselect goes
active. Changing polarity later would start a transfer. :)
> It sounds like with the new patch, I'll end up setting txrx_word[] to
> the same function for all modes.
Yes, it does sound like that. If that works for you, I'd like to see
that go into 2.6.17 kernels.
- Dave
^ permalink raw reply
* Re: [spi-devel-general] Re: question on spi_bitbang
From: David Brownell @ 2006-03-31 19:16 UTC (permalink / raw)
To: stephen; +Cc: Kumar Gala, spi-devel-general, linux kernel mailing list
In-Reply-To: <1143829180.4355.51.camel@ststephen.streetfiresound.com>
On Friday 31 March 2006 10:19 am, Stephen Street wrote:
> On Fri, 2006-03-31 at 10:11 -0800, David Brownell wrote:
> > I don't know how your particular hardware works, but if you have a
> > real SPI controller it would probably be more natural to have your
> > setup() function handle that mode register earlier, out of the main
> > transfer loop ... unless that mode register is shared among all
> > chipselects, in which case you'd use the setup_transfer() call for
> > that, inside the transfer loop. (That call hasn't yet been merged
> > into the mainline kernel yet; it's in the MM tree.)
> >
> Is setup_transfer() a change to framework API or just the bit_bang
> driver?
Just bitbang.
> > The chipselect() call should only affect the chipselect signal and,
> > when you're activating a chip, its initial clock polarity. Though
> > if you're not using the latest from the MM tree, that's also your
> > hook for ensuring that the SPI mode is set up right.
>
> Ditto?
Ditto. Though it should also be OK, come to think of it, to keep
doing SPI mode selection in chipselect(); that shouldn't break.
- Dave
^ permalink raw reply
* Re: [PATCH 2/4] locks: don't unnecessarily fail posix lock operations
From: Miklos Szeredi @ 2006-03-31 19:31 UTC (permalink / raw)
To: trond.myklebust; +Cc: akpm, linux-fsdevel, linux-kernel
In-Reply-To: <1143830693.8085.19.camel@lade.trondhjem.org>
> However you are also changing the behaviour of F_SETLK for the case
> where the user is trying to up/downgrade a set of existing READ/WRITE
> locks. Again you may end up with a situation where some of the existing
> locks get up/downgraded, and yet the lock request fails.
Can you please point out the exact case when this happens?
I've carefully reviewd the code, and found none.
Thanks,
Miklos
^ permalink raw reply
* Fix ia64 bitops: Full barrier on smp_mb__after_clear_bit()
From: Christoph Lameter @ 2006-03-31 19:31 UTC (permalink / raw)
To: linux-ia64
The Linux kernel works based on barriers and not on acquire and release
semantics. We cannot expect an acquire or release of clear_bit() to
provide the synchronization behavior expected by core kernel developers.
Not having the proper barriers may introduce subtle breakage.
So change IA64 to provide full barriers for smp_mb__after_clear_bit.
This is also the way that powerpc (which faces similar issues) implements
these macros.
include/asm-powerpc/bitops.h:
/*
* clear_bit doesn't imply a memory barrier
*/
#define smp_mb__before_clear_bit() smp_mb()
#define smp_mb__after_clear_bit() smp_mb()
Signed-off-by: Christoph Lameter <clameter@sgi.com>
Index: linux-2.6.16-mm2/include/asm-ia64/bitops.h
=================================--- linux-2.6.16-mm2.orig/include/asm-ia64/bitops.h 2006-03-30 21:21:04.000000000 -0800
+++ linux-2.6.16-mm2/include/asm-ia64/bitops.h 2006-03-31 11:17:53.000000000 -0800
@@ -63,10 +63,13 @@ __set_bit (int nr, volatile void *addr)
}
/*
- * clear_bit() has "acquire" semantics.
+ * The current linux locking paradigm is oriented towards
+ * barriers. We cannot utilize acquire or relase behaviors
+ * to synchronize but must implement full barriers in order
+ * to avoid potential subtle breakage.
*/
#define smp_mb__before_clear_bit() smp_mb()
-#define smp_mb__after_clear_bit() do { /* skip */; } while (0)
+#define smp_mb__after_clear_bit() smp_mb()
/**
* clear_bit - Clears a bit in memory
^ permalink raw reply
* Re: Questions about pseudo plugins
From: Alexander Zarochentsev @ 2006-03-31 19:30 UTC (permalink / raw)
To: reiserfs-list; +Cc: Yoanis Gil Delgado
In-Reply-To: <442C3900.1060808@uh.cu>
Hello
On Friday 31 March 2006 00:01, Yoanis Gil Delgado wrote:
> Hi there:
> I've been working on the versioning plugin.
> I will like to know how can i add a pseudo file to a pseudo
> directory, dynamically. I mean whenever i detect a new version i want
> to create a pseudo file under /file.txt/versioning/version/s pseudo
> directory. Another question is about how can I iterate over
> directories pseudo files.
IFAIK you need to define lookup and readdir methods for your pseudo
plugins.
Unfortunately it is very low level API for exporting your dynamic
structures. Some API like procfs/sysctl would be much better but
reiser4 does not have it yet.
> For example how i can iterate over the
> files under
> /file.txt/versioning/version/s (remember the files under this
> directory are pseudo files which are generated dynamically).
> I know there is a way to add static pseudo files and directories, by
> adding them to pseudo_plugins array. Perhaps using the linkage field
> from pseudo_plugin. I've some more questions but i will come later
> with them.
> By the way I found this in the patch for kernel 2.6.15:
> The function init_pseudo receives a _/const char* name /_which
> is never used.
> That's all for now. Thanks a lot .............. yoanis
--
Alex.
^ permalink raw reply
* [PATCH] 8250: yet another attempt at a serial console fix
From: Georg Nikodym @ 2006-03-31 19:29 UTC (permalink / raw)
To: linux-kernel; +Cc: rmk+serial, Georg Nikodym
[-- Attachment #1: Type: text/plain, Size: 4737 bytes --]
Various people have reported a problem in which the serial console
output gets stalled / stuck until a receive interrupt is received
(typically somebody hitting return a couple of times in an attempt to
see if the machine is still alive).
I'm working on an LSI based ARM SoC and as of 2.6.16, I too
experience this. For me the change that appears to have broken
things is where Alan Cox changed the following line in
serial8250_console_write() from:
serial_out(up, UART_IER, ier);
to:
serial_out(up, UART_IER, ier | UART_IER_THRI);
The documentation I have for my SoC, AMBA Multilayer Reference Design
Rev 2.0 TECHNICAL MANUAL (cw001202_MLRD2.0_TechManual.pdf) covers the
UART in chapter 10. There it describes the UART as 16550D compatible
with several listed behavioural changes. Specific to the THRE
interrupt, it says the following:
The previous version of the ApUart would trigger the THRE interrupt if
the THRE bit was set and the Enable Transmitter Holding Register Empty
Interrupt bit was changed from 0 to 1.
The new version does this only if the interrupt handler has not already
reported this condition (by a read of the IIR when a THRE interrupt
is the
highest priority pending interrupt). A new interrupt will only be
reported
by the new version if one or more characters are written to, and
eventually emptied out of, the THR or the Transmitter FIFO.
This appears to describe the behaviour observed by Alex Williamson
and addressed in his backup-timer-for-uarts-that-lose-interrupts-
take-3.patch (http://lkml.org/lkml/2006/1/21/93)
Since the old code worked I had trouble swallowing the backup timer
idea. But the detection logic worked a charm so I lifted that and
offer up the attached patch for evisceration.
-g
===== 8250.h 1.27 vs edited =====
--- 1.27/drivers/serial/8250.h 2006-01-04 14:43:24 -05:00
+++ edited/8250.h 2006-03-30 16:26:56 -05:00
@@ -50,6 +50,7 @@ struct serial8250_config {
#define UART_BUG_QUOT (1 << 0) /* UART has buggy quot LSB */
#define UART_BUG_TXEN (1 << 1) /* UART has buggy TX IIR status */
#define UART_BUG_NOMSR (1 << 2) /* UART has buggy MSR status bits
(Au1x00) */
+#define UART_BUG_THRI (1 << 3) /* UART has revised THRE int.
semantics */
#define PROBE_RSA (1 << 0)
#define PROBE_ANY (~0)
===== 8250.c 1.140 vs edited =====
--- 1.140/drivers/serial/8250.c 2006-03-30 14:34:11 -05:00
+++ edited/8250.c 2006-03-30 18:36:35 -05:00
@@ -298,6 +298,10 @@ static inline int map_8250_out_reg(struc
#endif
+#ifdef CONFIG_SERIAL_8250_CONSOLE
+static void thre_bug_test(struct uart_8250_port *up);
+#endif
+
static unsigned int serial_in(struct uart_8250_port *up, int offset)
{
offset = map_8250_in_reg(up, offset) << up->port.regshift;
@@ -1389,6 +1393,7 @@ static int serial_link_irq_chain(struct
irq_flags, "serial", i);
if (ret < 0)
serial_do_unlink(i, up);
+
}
return ret;
@@ -1623,6 +1628,10 @@ static int serial8250_startup(struct uar
up->bugs &= ~UART_BUG_TXEN;
}
+#ifdef CONFIG_SERIAL_8250_CONSOLE
+ thre_bug_test(up);
+#endif
+
spin_unlock_irqrestore(&up->port.lock, flags);
/*
@@ -2182,6 +2191,37 @@ static inline void wait_for_xmitr(struct
}
}
+static void thre_bug_test(struct uart_8250_port *up)
+{
+ unsigned char iir;
+
+ if (is_real_interrupt(up->port.irq) && !timer_pending(&up->timer)) {
+ /*
+ * Test for UARTs that do not reassert THRE when the
+ * transmitter is idle and the interrupt has already
+ * been cleared. Real 16550s should always reassert
+ * this interrupt whenever the transmitter is idle and
+ * the interrupt is enabled.
+ */
+ wait_for_xmitr(up, BOTH_EMPTY);
+ serial_outp(up, UART_IER, UART_IER_THRI);
+ (void)serial_in(up, UART_IIR);
+ serial_outp(up, UART_IER, 0);
+ serial_outp(up, UART_IER, UART_IER_THRI);
+ iir = serial_in(up, UART_IIR);
+ serial_outp(up, UART_IER, 0);
+
+ /*
+ * If the interrupt is not reasserted, setup a timer to
+ * kick the UART on a regular basis.
+ */
+ if (iir & UART_IIR_NO_INT) {
+ pr_debug("ttyS%d - enabling THRI workaround\n",
+ up->port.line);
+ }
+ }
+}
+
/*
* Print a string to the serial port trying not to disturb
* any possible real use of the port...
@@ -2229,9 +2269,12 @@ serial8250_console_write(struct console
* and restore the IER
*/
wait_for_xmitr(up, BOTH_EMPTY);
- // up->ier |= UART_IER_THRI;
- // serial_out(up, UART_IER, ier | UART_IER_THRI);
- serial_out(up, UART_IER, ier);
+ if (up->bugs & UART_BUG_THRI) {
+ serial_out(up, UART_IER, ier);
+ } else {
+ up->ier |= UART_IER_THRI;
+ serial_out(up, UART_IER, ier | UART_IER_THRI);
+ }
}
static int serial8250_console_setup(struct console *co, char *options)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* [ALSA - driver 0001988]: No microphone input on Dell Inspiron 6400
From: bugtrack @ 2006-03-31 19:28 UTC (permalink / raw)
To: alsa-devel
The following issue has been SUBMITTED.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1988>
======================================================================
Reported By: tbecker37
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 1988
Category: PCI - hda-intel
Reproducibility: always
Severity: major
Priority: normal
Status: assigned
Distribution: Fedora Core 5
Kernel Version: 2.6.16-1.2080_FC5smp
======================================================================
Date Submitted: 03-31-2006 21:28 CEST
Last Modified: 03-31-2006 21:28 CEST
======================================================================
Summary: No microphone input on Dell Inspiron 6400
Description:
Installing the 1.0.11rc4 driver enabled sound output both for extenal and
headphone jack. However microphone input does not work. Mic input is
displayed in alsamixer but is not adjustable.
I have also compiled and tried the driver from CVS on 3-31 with no
success.
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
03-31-06 21:28 tbecker37 New Issue
03-31-06 21:28 tbecker37 Distribution => Fedora Core 5
03-31-06 21:28 tbecker37 Kernel Version => 2.6.16-1.2080_FC5smp
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: The sort algorithm is broken by the second rule, We need a way to pin these rules to the top.
From: Stephen Smalley @ 2006-03-31 19:27 UTC (permalink / raw)
To: Joshua Brindle; +Cc: Christopher J. PeBenito, Daniel J Walsh, SE Linux
In-Reply-To: <442D47ED.6040007@tresys.com>
On Fri, 2006-03-31 at 10:17 -0500, Joshua Brindle wrote:
> Please note that the sorting algorithm is very much heuristic and not
> perfect. In the discussions we've had around here about this we
> determined that the correct solution is to make the regexes more
> specific where possible.
In the old scheme (example policy build), types.fc always went first,
followed by the program .fc files in arbitrary order, leaving the
ordering as specified within each file, and the goal was to put most
generic patterns only in types.fc (manually ordered by the policy writer
based on his goal for prioritization) and to minimize use of regexes
(particularly ones that were overly broad and lacked a reasonably
specific stem) in the individual program .fc files. Not saying that we
achieved that goal, but that was the approach.
Recent file_contexts seem to have _very_ broad regexes in an attempt to
cover many variations, but I think that this isn't good for
understanding.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: windows problems summary
From: Eric W. Biederman @ 2006-03-31 19:25 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List
In-Reply-To: <81b0412b0603020649u99a2035i3b8adde8ddce9410@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> writes:
> This is just to summarize all the problems which make porting to that
> thing so boring. Maybe if we have them all on one page, it'd be easier
> to locate the workarounds (it can be one thread, for example).
>
> 1. opened and mmaped files can't be removed or renamed
> (caused workaround with reading index in memory)
> 2. command can safely contain only one argument
> (breaks and complicates passing things between processes)
> 3. no fork
> (slows down and complicates passing things between processes)
> 4. non-unix permissions model
> (breaks x-attr)
> 5. real slow filesystems and caching
> (makes everything slow. I noticed I'm trying to avoid git status!).
> Caused workaround with manual checkout)
> 6. real slow program startup
> (makes everything slow, eventually may cause everything being put
> in one super-executable, just to avoid spawning new processes,
> with all associated problems. Makes scripting harder)
>
> I hope this message can be a start of a big porting thread,
> even though it is only about windows at the moment.
Not to forget make install gets confused when there
is a file named INSTALL in the git directory.
Eric
^ permalink raw reply
* [PATCH] Fix reversed test in balloon.py
From: Charles Coffing @ 2006-03-31 19:26 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1: Type: text/plain, Size: 291 bytes --]
When dom0 fails to balloon enough memory to allow a new domain to start,
an exception is thrown. The test that decides which exception to throw
is backwards, resulting in strange error messages. The attached patch
fixes the problem.
Signed-off-by: Charles Coffing <ccoffing@novell.com>
[-- Attachment #2: xen-balloon.diff --]
[-- Type: application/octet-stream, Size: 614 bytes --]
--- xen-unstable-1/tools/python/xen/xend/balloon.py 2006-03-14 12:50:58.000000000 -0700
+++ xen-unstable-2/tools/python/xen/xend/balloon.py 2006-03-31 11:35:20.000000000 -0700
@@ -152,7 +152,7 @@
'I cannot release any more. I need %d MiB but '
'only have %d.') %
(need_mem, free_mem))
- elif new_alloc >= dom0_min_mem:
+ elif new_alloc < dom0_min_mem:
raise VmError(
('I need %d MiB, but dom0_min_mem is %d and shrinking to '
'%d MiB would leave only %d MiB free.') %
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: [PATCH 2/4] locks: don't unnecessarily fail posix lock operations
From: Miklos Szeredi @ 2006-03-31 19:25 UTC (permalink / raw)
To: trond.myklebust; +Cc: akpm, linux-fsdevel, linux-kernel
In-Reply-To: <1143829641.8085.7.camel@lade.trondhjem.org>
> NACK.
>
> This changes the behaviour of F_UNLCK. Currently, if the allocation
> fails, the inode locking state remains unchanged. With your change, an
> unlock request may end up unlocking part of the inode, but not the rest.
No, look more closer. There are two cases:
- some locks are partially or completely removed
- the unlock splits an existing lock in two.
In the first case no new locks are needed. In the second, no locks
are modified prior to the check.
Miklos
^ permalink raw reply
* Re: [patch] PI-futex patchset: -V4
From: Ingo Molnar @ 2006-03-31 19:23 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, tglx, torvalds, Esben Nielsen
In-Reply-To: <20060331191445.GA2250@elte.hu>
* Ingo Molnar <mingo@elte.hu> wrote:
> this is version -V4 of the PI-futex patchset (ontop of current -mm2,
> which includes -V3.)
>
> A clean queue of split-up patches can be found at:
>
> http://redhat.com/~mingo/PI-futex-patches/PI-futex-patches-V4.tar.gz
oops, the plist debugging changes were missing from the delta. Find
incremental patch ontop of -V4 below. The tarball above contains all the
needed patches.
Ingo
-----
PI-futex -V4 part #2
Signed-off-by: Ingo Molnar <mingo@elte.hu>
--
include/asm-generic/bug.h | 6 ++++++
include/linux/plist.h | 29 +++++++++++++++++++++++++----
lib/plist.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 76 insertions(+), 4 deletions(-)
Index: linux-pi-futex.mm.q/include/asm-generic/bug.h
===================================================================
--- linux-pi-futex.mm.q.orig/include/asm-generic/bug.h
+++ linux-pi-futex.mm.q/include/asm-generic/bug.h
@@ -39,4 +39,10 @@
#endif
#endif
+#ifdef CONFIG_SMP
+# define WARN_ON_SMP(x) WARN_ON(x)
+#else
+# define WARN_ON_SMP(x) do { } while (0)
+#endif
+
#endif
Index: linux-pi-futex.mm.q/include/linux/plist.h
===================================================================
--- linux-pi-futex.mm.q.orig/include/linux/plist.h
+++ linux-pi-futex.mm.q/include/linux/plist.h
@@ -79,6 +79,9 @@
struct plist_head {
struct list_head prio_list;
struct list_head node_list;
+#ifdef CONFIG_DEBUG_PI_LIST
+ spinlock_t *lock;
+#endif
};
struct plist_node {
@@ -86,15 +89,22 @@ struct plist_node {
struct plist_head plist;
};
+#ifdef CONFIG_DEBUG_PI_LIST
+# define PLIST_HEAD_LOCK_INIT(_lock) .lock = _lock
+#else
+# define PLIST_HEAD_LOCK_INIT(_lock)
+#endif
+
/**
* #PLIST_HEAD_INIT - static struct plist_head initializer
*
* @head: struct plist_head variable name
*/
-#define PLIST_HEAD_INIT(head) \
+#define PLIST_HEAD_INIT(head, _lock) \
{ \
.prio_list = LIST_HEAD_INIT((head).prio_list), \
.node_list = LIST_HEAD_INIT((head).node_list), \
+ PLIST_HEAD_LOCK_INIT(&(_lock)) \
}
/**
@@ -115,10 +125,13 @@ struct plist_node {
* @head: &struct plist_head pointer
*/
static inline void
-plist_head_init(struct plist_head *head)
+plist_head_init(struct plist_head *head, spinlock_t *lock)
{
INIT_LIST_HEAD(&head->prio_list);
INIT_LIST_HEAD(&head->node_list);
+#ifdef CONFIG_DEBUG_PI_LIST
+ head->lock = lock;
+#endif
}
/**
@@ -130,7 +143,7 @@ plist_head_init(struct plist_head *head)
static inline void plist_node_init(struct plist_node *node, int prio)
{
node->prio = prio;
- plist_head_init(&node->plist);
+ plist_head_init(&node->plist, NULL);
}
extern void plist_add(struct plist_node *node, struct plist_head *head);
@@ -207,8 +220,16 @@ static inline int plist_node_empty(const
* @type: the type of the struct this is embedded in.
* @member: the name of the list_struct within the struct.
*/
-#define plist_first_entry(head, type, member) \
+#ifdef CONFIG_DEBUG_PI_LIST
+# define plist_first_entry(head, type, member) \
+({ \
+ WARN_ON(plist_head_empty(head)); \
+ container_of(plist_first(head), type, member); \
+})
+#else
+# define plist_first_entry(head, type, member) \
container_of(plist_first(head), type, member)
+#endif
/**
* plist_first - return the first node (and thus, highest priority)
Index: linux-pi-futex.mm.q/lib/plist.c
===================================================================
--- linux-pi-futex.mm.q.orig/lib/plist.c
+++ linux-pi-futex.mm.q/lib/plist.c
@@ -26,6 +26,44 @@
#include <linux/plist.h>
#include <linux/spinlock.h>
+#ifdef CONFIG_DEBUG_PI_LIST
+
+static void plist_check_prev_next(struct list_head *t, struct list_head *p,
+ struct list_head *n)
+{
+ if (n->prev != p || p->next != n) {
+ printk("top: %p, n: %p, p: %p\n", t, t->next, t->prev);
+ printk("prev: %p, n: %p, p: %p\n", p, p->next, p->prev);
+ printk("next: %p, n: %p, p: %p\n", n, n->next, n->prev);
+ WARN_ON(1);
+ }
+}
+
+static void plist_check_list(struct list_head *top)
+{
+ struct list_head *prev = top, *next = top->next;
+
+ plist_check_prev_next(top, prev, next);
+ while (next != top) {
+ prev = next;
+ next = prev->next;
+ plist_check_prev_next(top, prev, next);
+ }
+}
+
+static void plist_check_head(struct plist_head *head)
+{
+ WARN_ON(!head->lock);
+ if (head->lock)
+ WARN_ON_SMP(!spin_is_locked(head->lock));
+ plist_check_list(&head->prio_list);
+ plist_check_list(&head->node_list);
+}
+
+#else
+# define plist_check_head(h) do { } while (0)
+#endif
+
/**
* plist_add - add @node to @head
*
@@ -36,6 +74,7 @@ void plist_add(struct plist_node *node,
{
struct plist_node *iter;
+ plist_check_head(head);
WARN_ON(!plist_node_empty(node));
list_for_each_entry(iter, &head->prio_list, plist.prio_list) {
@@ -52,6 +91,8 @@ lt_prio:
list_add_tail(&node->plist.prio_list, &iter->plist.prio_list);
eq_prio:
list_add_tail(&node->plist.node_list, &iter->plist.node_list);
+
+ plist_check_head(head);
}
/**
@@ -62,6 +103,8 @@ eq_prio:
*/
void plist_del(struct plist_node *node, struct plist_head *head)
{
+ plist_check_head(head);
+
if (!list_empty(&node->plist.prio_list)) {
struct plist_node *next = plist_first(&node->plist);
@@ -70,4 +113,6 @@ void plist_del(struct plist_node *node,
}
list_del_init(&node->plist.node_list);
+
+ plist_check_head(head);
}
^ permalink raw reply
* Re: [PATCH] Rework of IPC auditing
From: Steve Grubb @ 2006-03-31 19:24 UTC (permalink / raw)
To: linux-audit, dustin.kirkland
In-Reply-To: <1142018719.13416.91.camel@kirkland1.austin.ibm.com>
On Friday 10 March 2006 14:25, Dustin Kirkland wrote:
> 2) Support for an AUDIT_IPC_NEW_PERM audit message type. This allows
> for separate auxiliary audit records for normal operations on an IPC
> object and permissions changes. Note that the same struct
> audit_aux_data_ipcctl is used and populated, however there are separate
> audit_log_format statements based on the type of the message.
Can we have another name for this record type? I don't want us to get in the
habit of adding "new" to the record type name. Is there something that better
describes its purpose?
-Steve
^ permalink raw reply
* [RFC][patch] console_flush()
From: Jimi Xenidis @ 2006-03-31 19:24 UTC (permalink / raw)
To: xen-devel
It occurs to me that since console_sync_start/stop use ++ and --
respectively, that it was designed to be "nested" and bracket code
segments. If this is indeed desirable than perhaps we need another
interface that simply flushed the console.
The only real use I can see for it is to flush after the panic
message rather than using console_sync_start() before it.
Patch below.
thoughts?
-JX
Signed-off-by: Jimi Xenidis <jimix@watson.ibm.com>
---
diff -r d76a7a40f3a9 xen/drivers/char/console.c
--- a/xen/drivers/char/console.c Fri Mar 31 17:44:26 2006 +0100
+++ b/xen/drivers/char/console.c Fri Mar 31 13:12:16 2006 -0500
@@ -526,6 +526,11 @@ void console_force_lock(void)
spin_lock(&console_lock);
}
+void console_flush(void)
+{
+ serial_flush(sercon_handle);
+}
+
void console_start_sync(void)
{
serial_start_sync(sercon_handle);
@@ -684,7 +689,6 @@ void panic(const char *fmt, ...)
va_end(args);
/* Spit out multiline message in one go. */
- console_start_sync();
spin_lock_irqsave(&lock, flags);
printk("\n****************************************\n");
printk("Panic on CPU %d:\n", smp_processor_id());
@@ -692,6 +696,7 @@ void panic(const char *fmt, ...)
printk("****************************************\n\n");
printk("Reboot in five seconds...\n");
spin_unlock_irqrestore(&lock, flags);
+ console_flush();
debugger_trap_immediate();
diff -r d76a7a40f3a9 xen/drivers/char/serial.c
--- a/xen/drivers/char/serial.c Fri Mar 31 17:44:26 2006 +0100
+++ b/xen/drivers/char/serial.c Fri Mar 31 13:12:16 2006 -0500
@@ -301,6 +301,30 @@ void serial_force_unlock(int handle)
serial_start_sync(handle);
}
+static void serial_flush_locked(struct serial_port *port)
+{
+ while ( (port->txbufp - port->txbufc) != 0 )
+ {
+ while ( !port->driver->tx_empty(port) )
+ cpu_relax();
+ port->driver->putc(
+ port, port->txbuf[MASK_SERIAL_TXBUF_IDX(port->txbufc++)]);
+ }
+}
+
+void serial_flush(int handle)
+{
+ struct serial_port *port = &com[handle & SERHND_IDX];
+ unsigned long flags;
+
+ if ( handle == -1 )
+ return;
+
+ spin_lock_irqsave(&port->tx_lock, flags);
+ serial_flush_locked(port);
+ spin_unlock_irqrestore(&port->tx_lock, flags);
+};
+
void serial_start_sync(int handle)
{
struct serial_port *port = &com[handle & SERHND_IDX];
@@ -311,16 +335,8 @@ void serial_start_sync(int handle)
spin_lock_irqsave(&port->tx_lock, flags);
- if ( port->sync++ == 0 )
- {
- while ( (port->txbufp - port->txbufc) != 0 )
- {
- while ( !port->driver->tx_empty(port) )
- cpu_relax();
- port->driver->putc(
- port, port->txbuf[MASK_SERIAL_TXBUF_IDX(port->txbufc+
+)]);
- }
- }
+ port->sync++;
+ serial_flush_locked(port);
spin_unlock_irqrestore(&port->tx_lock, flags);
}
diff -r d76a7a40f3a9 xen/include/xen/console.h
--- a/xen/include/xen/console.h Fri Mar 31 17:44:26 2006 +0100
+++ b/xen/include/xen/console.h Fri Mar 31 13:12:16 2006 -0500
@@ -22,6 +22,7 @@ void console_force_unlock(void);
void console_force_unlock(void);
void console_force_lock(void);
+void console_flush(void);
void console_start_sync(void);
void console_end_sync(void);
diff -r d76a7a40f3a9 xen/include/xen/serial.h
--- a/xen/include/xen/serial.h Fri Mar 31 17:44:26 2006 +0100
+++ b/xen/include/xen/serial.h Fri Mar 31 13:12:16 2006 -0500
@@ -93,6 +93,7 @@ void serial_force_unlock(int handle);
void serial_force_unlock(int handle);
/* Start/end a synchronous region (temporarily disable interrupt-
driven tx). */
+void serial_flush(int handle);
void serial_start_sync(int handle);
void serial_end_sync(int handle);
^ permalink raw reply
* ACPI Error (Method parse/execution failed) with 2.6.16 kernel
From: Maurizio Lombardi @ 2006-03-31 19:20 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-acpi
[-- Attachment #1: Type: text/plain, Size: 357 bytes --]
Hi,
I had some problems switching from 2.6.15.6 to 2.6.16 kernel version.
At boot sometimes i get some errors about ACPI, you can find logs as attachment.
As a result, sometimes my laptop is unable to read battery remaining
capacity level.
Do you know how to fix this problem?
--
--------------------
Maurizio Lombardi
Linux 2.6.16
--------------------
[-- Attachment #2: dmesg --]
[-- Type: application/octet-stream, Size: 11266 bytes --]
Linux version 2.6.16 (rokeby@darkstar) (gcc version 3.3.4) #3 Wed Mar 22 13:13:48 CET 2006
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000d0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000000f6f0000 (usable)
BIOS-e820: 000000000f6f0000 - 000000000f6ff000 (ACPI data)
BIOS-e820: 000000000f6ff000 - 000000000f700000 (ACPI NVS)
BIOS-e820: 000000000f700000 - 000000000f800000 (reserved)
BIOS-e820: 00000000fffc0000 - 0000000100000000 (reserved)
246MB LOWMEM available.
On node 0 totalpages: 63216
DMA zone: 4096 pages, LIFO batch:0
DMA32 zone: 0 pages, LIFO batch:0
Normal zone: 59120 pages, LIFO batch:15
HighMem zone: 0 pages, LIFO batch:0
DMI 2.3 present.
ACPI: RSDP (v000 PTLTD ) @ 0x000f7290
ACPI: RSDT (v001 PTLTD RSDT 0x06040000 LTP 0x00000000) @ 0x0f6f8b67
ACPI: FADT (v001 ATI Raptor 0x06040000 ATI 0x000f4240) @ 0x0f6fee2b
ACPI: BOOT (v001 PTLTD $SBFTBL$ 0x06040000 LTP 0x00000001) @ 0x0f6fee9f
ACPI: SSDT (v001 PTLTD POWERNOW 0x06040000 LTP 0x00000001) @ 0x0f6feec7
ACPI: DSDT (v001 ATI U1_M1535 0x06040000 MSFT 0x0100000d) @ 0x00000000
ACPI: PM-Timer IO Port: 0x8008
Allocating PCI resources starting at 10000000 (gap: 0f800000:f07c0000)
Built 1 zonelists
Kernel command line: BOOT_IMAGE=Linux-2.6.16 ro root=301
Local APIC disabled by BIOS -- you can enable it with "lapic"
mapped APIC to ffffd000 (011ef000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 1024 (order: 10, 16384 bytes)
Detected 1855.214 MHz processor.
Using pmtmr for high-res timesource
Console: colour dummy device 80x25
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 247460k/252864k available (1712k kernel code, 4852k reserved, 628k data, 152k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 3713.82 BogoMIPS (lpj=7427650)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0383f9ff c1cbf9ff 00000000 00000000 00000000 00000000 00000000
CPU: After vendor identify, caps: 0383f9ff c1cbf9ff 00000000 00000000 00000000 00000000 00000000
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU: After all inits, caps: 0383f9ff c1cbf9ff 00000000 00000020 00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: AMD mobile AMD Athlon(tm) XP2500+ stepping 00
Checking 'hlt' instruction... OK.
ACPI: setting ELCR to 0200 (from 0e28)
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfd87b, last bus=2
PCI: Using configuration type 1
ACPI: Subsystem revision 20060127
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
PCI quirk: region 8000-803f claimed by ali7101 ACPI
PCI quirk: region 8040-805f claimed by ali7101 SMB
Boot video device is 0000:01:05.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGPB._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 6 *10)
ACPI: PCI Interrupt Link [LNKB] (IRQs 7 *11)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 6 10) *0, disabled.
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 6 10) *0, disabled.
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 6 10) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 7 11) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs *3 4 6 10)
ACPI: PCI Interrupt Link [LNKH] (IRQs *5 7)
ACPI: PCI Interrupt Link [LNKU] (IRQs 3 4 6 10) *9
ACPI: Embedded Controller [EC0] (gpe 24) interrupt mode.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 11 devices
SCSI subsystem initialized
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
pnp: 00:07: ioport range 0x40b-0x40b has been reserved
pnp: 00:07: ioport range 0x480-0x48f has been reserved
pnp: 00:07: ioport range 0x4d0-0x4d1 has been reserved
pnp: 00:07: ioport range 0x4d6-0x4d6 has been reserved
pnp: 00:07: ioport range 0x8000-0x807f could not be reserved
PCI: Bridge: 0000:00:01.0
IO window: 9000-9fff
MEM window: e4100000-e41fffff
PREFETCH window: ec000000-edffffff
PCI: Bus 2, cardbus bridge: 0000:00:0a.0
IO window: 00001000-000010ff
IO window: 00001400-000014ff
PREFETCH window: 10000000-11ffffff
MEM window: 12000000-13ffffff
PCI: Enabling device 0000:00:0a.0 (0000 -> 0003)
ACPI: PCI Interrupt Link [LNKF] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [LNKF] -> GSI 11 (level, low) -> IRQ 11
PCI: Setting latency timer of device 0000:00:0a.0 to 64
Simple Boot Flag at 0x36 set to 0x1
Machine check exception polling timer started.
io scheduler noop registered
io scheduler anticipatory registered
io scheduler cfq registered (default)
ATI Northbridge, reserving I/O ports 0x3b0 to 0x3bb.
Activating ISA DMA hang workarounds.
vesafb: framebuffer at 0xec000000, mapped to 0xd0080000, using 3072k, total 8128k
vesafb: mode is 1024x768x16, linelength=2048, pages=4
vesafb: protected mode interface info at c000:51a9
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:5:5, shift=0:10:5:0
Console: switching to colour frame buffer device 128x48
fb0: VESA VGA frame buffer device
ACPI: AC Adapter [ACAD] (on-line)
ACPI: Battery Slot [BAT1] (battery absent)
ACPI: Power Button (FF) [PWRF]
ACPI: Power Button (CM) [PWRB]
ACPI: Lid Switch [LID]
ACPI: Video Device [VGA] (multi-head: yes rom: no post: no)
ACPI: CPU0 (power states: C1[C1] C2[C2])
ACPI: Thermal Zone [THRM] (52 C)
PNP: PS/2 Controller [PNP0303:KBC0,PNP0f13:MSE0] at 0x60,0x64 irq 1,12
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ACPI: PCI Interrupt Link [LNKG] enabled at IRQ 3
PCI: setting IRQ 3 as level-triggered
ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [LNKG] -> GSI 3 (level, low) -> IRQ 3
0000:00:08.0: ttyS1 at I/O 0x8828 (irq = 3) is a 8250
0000:00:08.0: ttyS2 at I/O 0x8840 (irq = 3) is a 8250
0000:00:08.0: ttyS3 at I/O 0x8850 (irq = 3) is a 8250
Couldn't register serial port 0000:00:08.0: -28
natsemi dp8381x driver, version 1.07+LK1.0.17, Sep 27, 2002
originally by Donald Becker <becker@scyld.com>
http://www.scyld.com/network/natsemi.html
2.4.x kernel port by Jeff Garzik, Tjeerd Mulder
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:12.0[A] -> Link [LNKB] -> GSI 11 (level, low) -> IRQ 11
natsemi eth0: NatSemi DP8381[56] at 0xe4003000 (0000:00:12.0), 00:0f:20:c7:7f:8d, IRQ 11, port TP.
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
alim15x3: ATI Radeon IGP Northbridge is not yet fully tested.
ALI15X3: IDE controller at PCI slot 0000:00:10.0
ACPI: PCI Interrupt 0000:00:10.0[A]: no GSI
ALI15X3: chipset revision 196
ALI15X3: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0x8080-0x8087, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0x8088-0x808f, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
hda: ST94019A, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: _NEC DVD+RW ND-5100A, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 78140160 sectors (40007 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(100)
hda: cache flushes supported
hda: hda1 hda2
hdc: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, DMA
Uniform CD-ROM driver Revision: 3.20
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
input: AT Translated Set 2 keyboard as /class/input/input0
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 3, 32768 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
powernow: PowerNOW! Technology present. Can scale: frequency and voltage.
Detected 1855.236 MHz processor.
powernow: No PST tables match this cpuid (0x7a0)
powernow: This is indicative of a broken BIOS.
powernow: Trying ACPI perflib
powernow: Minimum speed 530 MHz. Maximum speed 1855 MHz.
Using IPI Shortcut mode
ACPI wakeup devices:
PCI0 MDEM LAN LID
ACPI: (supports S0 S3 S4 S5)
ReiserFS: hda1: found reiserfs format "3.6" with standard journal
ACPI: read EC, OB not full
ACPI Exception (evregion-0409): AE_TIME, Returned by Handler for [EmbeddedControl] [20060127]
ACPI Exception (dswexec-0458): AE_TIME, While resolving operands for [AE_NOT_CONFIGURED] [20060127]
ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.PCI0.ISA_.EC0_.SMRD] (Node c122bbe0), AE_TIME
ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.PCI0.ISA_.EC0_.SMSL] (Node c122bb80), AE_TIME
ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.PCI0.ISA_.EC0_._Q09] (Node c122bae0), AE_TIME
Synaptics Touchpad, model: 1, fw: 5.9, id: 0x236eb3, caps: 0x904713/0x10008
input: SynPS/2 Synaptics TouchPad as /class/input/input1
ReiserFS: hda1: using ordered data mode
ReiserFS: hda1: journal params: device hda1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: hda1: checking transaction log (hda1)
ReiserFS: hda1: Using r5 hash to sort names
VFS: Mounted root (reiserfs filesystem) readonly.
Freeing unused kernel memory: 152k freed
Adding 594396k swap on /dev/hda2. Priority:-1 extents:1 across:594396k
Linux agpgart interface v0.101 (c) Dave Jones
ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 5
PCI: setting IRQ 5 as level-triggered
ACPI: PCI Interrupt 0000:00:06.0[A] -> Link [LNKH] -> GSI 5 (level, low) -> IRQ 5
AC'97 1 does not respond - RESET
AC'97 1 access is not valid [0xffffffff], removing mixer.
ali mixer 1 creating error.
usbcore: registered new driver usbfs
usbcore: registered new driver hub
ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
ACPI: PCI Interrupt Link [LNKU] enabled at IRQ 10
PCI: setting IRQ 10 as level-triggered
ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LNKU] -> GSI 10 (level, low) -> IRQ 10
ohci_hcd 0000:00:02.0: OHCI Host Controller
ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 1
ohci_hcd 0000:00:02.0: irq 10, io mem 0xe4000000
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 4 ports detected
agpgart: Detected Ati IGP320/M chipset
agpgart: AGP aperture is 64M @ 0xe8000000
input: PC Speaker as /class/input/input2
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP(,...)]
^ permalink raw reply
* Re: Documentation up to date?
From: Charles Coffing @ 2006-03-31 19:19 UTC (permalink / raw)
To: jimmy Pierre, xen-devel
In-Reply-To: <c3f6eb940603310116i3267cf6l63f3dfbf5eeab8bd@mail.gmail.com>
yast2-vm version 2.13.28 or later has the support you want (if I
understand your question correctly). It can create a VM from scratch,
or it can re-use an existing disk image. It is included in SLES 10 beta
9 (released yesterday). It should also be in OpenSUSE and SUSE Linux
10.1, but I don't have their release schedules handy.
HTH,
Chuck
>>> On Fri, Mar 31, 2006 at 2:16 AM, in message
<c3f6eb940603310116i3267cf6l63f3dfbf5eeab8bd@mail.gmail.com>, "jimmy
Pierre"
<jimmypierre.rouen.france@gmail.com> wrote:
> Greetings,
>
> If any of you know of the documentation for importing images with
Yast, you
> could save my week end!
>
> I have finally managed to have Xen 3. on Beta 1.8 of OpenSuSe
> 10.1installed. I have images that XenFr has given me (Thanks
Antoine)
> So before
> messing everything, I need to find out abour how Yast will impotrt
these
> images.
>
> Best wishes,
>
> Jimmy Pierre
> President
> NUI.fr
^ permalink raw reply
* Re: The sort algorithm is broken by the second rule, We need a way to pin these rules to the top.
From: Joshua Brindle @ 2006-03-31 19:18 UTC (permalink / raw)
To: sds; +Cc: Ivan Gyurdiev, Christopher J. PeBenito, Daniel J Walsh, SE Linux
In-Reply-To: <1143832535.17469.29.camel@moss-spartans.epoch.ncsc.mil>
Stephen Smalley wrote:
> On Fri, 2006-03-31 at 14:03 -0500, Ivan Gyurdiev wrote:
>>> Sorting is presently only
>>> happening in the policy build process via the
>>> refpolicy/support/fc_sort.c helper program, so it is only applied to the
>>> file_context file provided by the policy itself, not to any local
>>> entries (whether created via semanage or not).
>>>
>> My mistake, I thought sorting was moved into matchpathcon at some point...
>> In that case the patch I sent shouldn't be necessary.
>
> Yes, Joshua had sent a patch to add the sorting logic to matchpathcon
> back in Oct '05, but I rejected it at the time because it needed to be
> coordinated with a policy update to ensure no actual change in
> filesystem labeling and because it sorted all of the file_contexts.*
> files together rather than retaining a prioritization among them. And
> as we later agreed, it belongs in libsemanage at generation time rather
> than in libselinux.
>
> Current libselinux matchpathcon logic only moves exact specifications
> (no regex in the pathname) to the end so that they are never overridden
> by a pathname regex; otherwise, it just uses the provided ordering
> within each file and it uses a fixed ordering among the files
> (file_contexts.local takes precedence over file_contexts.homedirs which
> takes precedence over file_contexts).
>
> What is a little confusing right now is that there are potentially two
> "file_contexts.local" files; the one managed via semanage that only
> exists in the store and is merged to the end of the generated
> file_contexts file for installation and the one that can be manually
> created by the admin that is "merged" to the end of the in-memory table
> by matchpathcon. I suppose we should consider the latter to be
> deprecated but libselinux will continue to look for it for legacy
> support.
>
I think libsemanage should just put the .local file out for libselinux
to read. There is no guarantee that none of the entries on .local won't
be preceded by something in the normal file context if it is merged in
libsemanage. This is the same thing we do for file_contexts.homedirs so
why not do it with .local? (Also, if we merge .local into the normal fc
file then the .local can't override .homedirs)
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: Non-Fatal Error PCI Express messages
From: Jurgen Kramer @ 2006-03-31 19:18 UTC (permalink / raw)
To: Dave Peterson; +Cc: linux-kernel, bluesmoke-devel
In-Reply-To: <200603311022.56896.dsp@llnl.gov>
On Fri, 2006-03-31 at 10:22 -0800, Dave Peterson wrote:
> On Friday 31 March 2006 00:25, Jurgen Kramer wrote:
> > With 2.6.16 (from FC5s 2.6.16-1.2080_FC5smp) I am getting a lot of
> >
> > Mar 31 09:35:16 paragon kernel: Non-Fatal Error PCI Express B
> > Mar 31 09:35:17 paragon kernel: Non-Fatal Error PCI Express B
> > Mar 31 09:35:17 paragon kernel: Non-Fatal Error PCI Express B
> > Mar 31 09:35:18 paragon kernel: Non-Fatal Error PCI Express B
> > Mar 31 09:35:18 paragon kernel: Non-Fatal Error PCI Express B
> > Mar 31 09:35:20 paragon kernel: Non-Fatal Error PCI Express B
> > Mar 31 09:35:20 paragon kernel: Non-Fatal Error PCI Express B
> > Mar 31 09:35:39 paragon kernel: Non-Fatal Error PCI Express B
> >
> > messages which presumably come from
> >
> > Mar 31 09:17:15 paragon kernel: MC: drivers/edac/edac_mc.c version
> > edac_mc Ver: 2.0.0 Mar 28 2006
> > Mar 31 09:17:15 paragon kernel: EDAC MC0: Giving out device to
> > "e752x_edac" E7525: PCI 0000:00:00.0
> >
> > Is there really something broken here of just a noisy driver?
> >
> > BTW this is on a Asus NCT-D mobo with Intel E7525 chipset.
> >
> > Jurgen
>
> Hi Jurgen,
>
> I haven't seen this particular error before, and I can't say for sure
> whether it's a genuine problem that should be dealt with or just a
> minor annoyance that can be safely ignored. EDAC is a relatively new
> piece of code, and still very much a work in progress. If this is in
> fact a benign type of error, EDAC should provide a mechanism by which
> a sysadmin can silence it. This is an area of future work.
>
> I'm forwarding your message to the bluesmoke mailing list just in
> case anyone who reads that list has seen instances of this error in
> the past and can provide more info on it.
>
> Dave
Hi Dave,
So far the system is running just fine. For reference, so far I found 92
"Non-Fatal Error PCI Express B" messages since the system was booted 8
hours ago.
BTW Dave Jones reported similar problems on the LKML:
http://lkml.org/lkml/2006/1/26/381
Cheers,
Jurgen
^ permalink raw reply
* [patch] PI-futex patchset: -V4
From: Ingo Molnar @ 2006-03-31 19:14 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, tglx, torvalds, Esben Nielsen
In-Reply-To: <20060326231638.GA18395@elte.hu>
this is version -V4 of the PI-futex patchset (ontop of current -mm2,
which includes -V3.)
A clean queue of split-up patches can be found at:
http://redhat.com/~mingo/PI-futex-patches/PI-futex-patches-V4.tar.gz
the -V4 codebase has been tested on the glibc code (all testcases pass)
and under load as well. (The -V4 code is included in the 2.6.16-rt12
code as well that i released earlier today.)
Changes since -V3:
- added Esben Nielsen's PI locking code, Thomas Gleixner made it
work in cornercases and under load. This is significantly simpler (it
removes 50 lines of code from rtmutex.c). The main difference is that
instead of holding all locks along a dependency chain, this code
propagates PI priorities (and detects deadlocks) by holding at most
two locks at once, and by being preemptible between such steps.
- Jakub Jelinek did a detailed review of the new futex code and found
some new races, which Thomas Gleixner fixed.
- to fix a pthread_mutex_trylock() related race, FUTEX_TRYLOCK_PI has
been added (Thomas Gleixner)
- documentation fixes based on feedback from Tim Bird
- added Documentation/pi-futex.txt (in addition to rt-mutex.txt)
- added the plist debugging patch (which was part of -rt but wasnt part
of the pi-futex queue before). This caught a couple of SMP bugs in
the past.
- implemented more scalable held-locks debugging - it's now a per-task
list of held locks, instead of a global list. This is similarly
effective to the global list, but much more scalable. (This approach
will also be added to the stock kernel/mutex.c code.)
- do not fiddle with irq flags in rtmutex.c - it's not needed.
- clone/fork fix: do not let parent's potential PI priority 'leak' into
child threads or processes.
- added /proc/sys/kernel/max_lock_depth with a default limit of 1024,
to limit the amount of deadlock-checking the kernel will do.
- small enhancement to the t3-l1-pi-signal.tst testcase.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
--
Documentation/rtmutex.txt | 60 -
linux-pi-futex.mm.q/Documentation/pi-futex.txt | 121 +++
linux-pi-futex.mm.q/Documentation/robust-futexes.txt | 2
linux-pi-futex.mm.q/Documentation/rt-mutex.txt | 74 +
linux-pi-futex.mm.q/include/linux/futex.h | 1
linux-pi-futex.mm.q/include/linux/rtmutex.h | 16
linux-pi-futex.mm.q/include/linux/sched.h | 9
linux-pi-futex.mm.q/include/linux/sysctl.h | 1
linux-pi-futex.mm.q/kernel/fork.c | 8
linux-pi-futex.mm.q/kernel/futex.c | 88 +-
linux-pi-futex.mm.q/kernel/rtmutex-debug.c | 186 ++--
linux-pi-futex.mm.q/kernel/rtmutex-debug.h | 9
linux-pi-futex.mm.q/kernel/rtmutex.c | 560 +++++---------
linux-pi-futex.mm.q/kernel/rtmutex.h | 3
linux-pi-futex.mm.q/kernel/sched.c | 8
linux-pi-futex.mm.q/kernel/sysctl.c | 15
linux-pi-futex.mm.q/scripts/rt-tester/t3-l1-pi-signal.tst | 3
17 files changed, 631 insertions(+), 533 deletions(-)
Index: linux-pi-futex.mm.q/Documentation/pi-futex.txt
===================================================================
--- /dev/null
+++ linux-pi-futex.mm.q/Documentation/pi-futex.txt
@@ -0,0 +1,121 @@
+Lightweight PI-futexes
+----------------------
+
+We are calling them lightweight for 3 reasons:
+
+ - in the user-space fastpath a PI-enabled futex involves no kernel work
+ (or any other PI complexity) at all. No registration, no extra kernel
+ calls - just pure fast atomic ops in userspace.
+
+ - even in the slowpath, the system call and scheduling pattern is very
+ similar to normal futexes.
+
+ - the in-kernel PI implementation is streamlined around the mutex
+ abstraction, with strict rules that keep the implementation
+ relatively simple: only a single owner may own a lock (i.e. no
+ read-write lock support), only the owner may unlock a lock, no
+ recursive locking, etc.
+
+Priority Inheritance - why?
+---------------------------
+
+The short reply: user-space PI helps achieving/improving determinism for
+user-space applications. In the best-case, it can help achieve
+determinism and well-bound latencies. Even in the worst-case, PI will
+improve the statistical distribution of locking related application
+delays.
+
+The longer reply:
+-----------------
+
+Firstly, sharing locks between multiple tasks is a common programming
+technique that often cannot be replaced with lockless algorithms. As we
+can see it in the kernel [which is a quite complex program in itself],
+lockless structures are rather the exception than the norm - the current
+ratio of lockless vs. locky code for shared data structures is somewhere
+between 1:10 and 1:100. Lockless is hard, and the complexity of lockless
+algorithms often endangers to ability to do robust reviews of said code.
+I.e. critical RT apps often choose lock structures to protect critical
+data structures, instead of lockless algorithms. Furthermore, there are
+cases (like shared hardware, or other resource limits) where lockless
+access is mathematically impossible.
+
+Media players (such as Jack) are an example of reasonable application
+design with multiple tasks (with multiple priority levels) sharing
+short-held locks: for example, a highprio audio playback thread is
+combined with medium-prio construct-audio-data threads and low-prio
+display-colory-stuff threads. Add video and decoding to the mix and
+we've got even more priority levels.
+
+So once we accept that synchronization objects (locks) are an
+unavoidable fact of life, and once we accept that multi-task userspace
+apps have a very fair expectation of being able to use locks, we've got
+to think about how to offer the option of a deterministic locking
+implementation to user-space.
+
+Most of the technical counter-arguments against doing priority
+inheritance only apply to kernel-space locks. But user-space locks are
+different, there we cannot disable interrupts or make the task
+non-preemptible in a critical section, so the 'use spinlocks' argument
+does not apply (user-space spinlocks have the same priority inversion
+problems as other user-space locking constructs). Fact is, pretty much
+the only technique that currently enables good determinism for userspace
+locks (such as futex-based pthread mutexes) is priority inheritance:
+
+Currently (without PI), if a high-prio and a low-prio task shares a lock
+[this is a quite common scenario for most non-trivial RT applications],
+even if all critical sections are coded carefully to be deterministic
+(i.e. all critical sections are short in duration and only execute a
+limited number of instructions), the kernel cannot guarantee any
+deterministic execution of the high-prio task: any medium-priority task
+could preempt the low-prio task while it holds the shared lock and
+executes the critical section, and could delay it indefinitely.
+
+Implementation:
+---------------
+
+As mentioned before, the userspace fastpath of PI-enabled pthread
+mutexes involves no kernel work at all - they behave quite similarly to
+normal futex-based locks: a 0 value means unlocked, and a value==TID
+means locked. (This is the same method as used by list-based robust
+futexes.) Userspace uses atomic ops to lock/unlock these mutexes without
+entering the kernel.
+
+To handle the slowpath, we have added two new futex ops:
+
+ FUTEX_LOCK_PI
+ FUTEX_UNLOCK_PI
+
+If the lock-acquire fastpath fails, [i.e. an atomic transition from 0 to
+TID fails], then FUTEX_LOCK_PI is called. The kernel does all the
+remaining work: if there is no futex-queue attached to the futex address
+yet then the code looks up the task that owns the futex [it has put its
+own TID into the futex value], and attaches a 'PI state' structure to
+the futex-queue. The pi_state includes an rt-mutex, which is a PI-aware,
+kernel-based synchronization object. The 'other' task is made the owner
+of the rt-mutex, and the FUTEX_WAITERS bit is atomically set in the
+futex value. Then this task tries to lock the rt-mutex, on which it
+blocks. Once it returns, it has the mutex acquired, and it sets the
+futex value to its own TID and returns. Userspace has no other work to
+perform - it now owns the lock, and futex value contains
+FUTEX_WAITERS|TID.
+
+If the unlock side fastpath succeeds, [i.e. userspace manages to do a
+TID -> 0 atomic transition of the futex value], then no kernel work is
+triggered.
+
+If the unlock fastpath fails (because the FUTEX_WAITERS bit is set),
+then FUTEX_UNLOCK_PI is called, and the kernel unlocks the futex on the
+behalf of userspace - and it also unlocks the attached
+pi_state->rt_mutex and thus wakes up any potential waiters.
+
+Note that under this approach, contrary to previous PI-futex approaches,
+there is no prior 'registration' of a PI-futex. [which is not quite
+possible anyway, due to existing ABI properties of pthread mutexes.]
+
+Also, under this scheme, 'robustness' and 'PI' are two orthogonal
+properties of futexes, and all four combinations are possible: futex,
+robust-futex, PI-futex, robust+PI-futex.
+
+More details about priority inheritance can be found in
+Documentation/rtmutex.txt.
Index: linux-pi-futex.mm.q/Documentation/robust-futexes.txt
===================================================================
--- linux-pi-futex.mm.q.orig/Documentation/robust-futexes.txt
+++ linux-pi-futex.mm.q/Documentation/robust-futexes.txt
@@ -95,7 +95,7 @@ comparison. If the thread has registered
is empty. If the thread/process crashed or terminated in some incorrect
way then the list might be non-empty: in this case the kernel carefully
walks the list [not trusting it], and marks all locks that are owned by
-this thread with the FUTEX_OWNER_DEAD bit, and wakes up one waiter (if
+this thread with the FUTEX_OWNER_DIED bit, and wakes up one waiter (if
any).
The list is guaranteed to be private and per-thread at do_exit() time,
Index: linux-pi-futex.mm.q/Documentation/rt-mutex.txt
===================================================================
--- /dev/null
+++ linux-pi-futex.mm.q/Documentation/rt-mutex.txt
@@ -0,0 +1,74 @@
+RT-mutex subsystem with PI support
+----------------------------------
+
+RT-mutexes with priority inheritance are used to support PI-futexes,
+which enable pthread_mutex_t priority inheritance attributes
+(PTHREAD_PRIO_INHERIT). [See Documentation/pi-futex.txt for more details
+about PI-futexes.]
+
+This technology was developed in the -rt tree and streamlined for
+pthread_mutex support.
+
+Basic principles:
+-----------------
+
+RT-mutexes extend the semantics of simple mutexes by the priority
+inheritance protocol.
+
+A low priority owner of a rt-mutex inherits the priority of a higher
+priority waiter until the rt-mutex is released. If the temporarily
+boosted owner blocks on a rt-mutex itself it propagates the priority
+boosting to the owner of the other rt_mutex it gets blocked on. The
+priority boosting is immediately removed once the rt_mutex has been
+unlocked.
+
+This approach allows us to shorten the block of high-prio tasks on
+mutexes which protect shared resources. Priority inheritance is not a
+magic bullet for poorly designed applications, but it allows
+well-designed applications to use userspace locks in critical parts of
+an high priority thread, without losing determinism.
+
+The enqueueing of the waiters into the rtmutex waiter list is done in
+priority order. For same priorities FIFO order is chosen. For each
+rtmutex, only the top priority waiter is enqueued into the owner's
+priority waiters list. This list too queues in priority order. Whenever
+the top priority waiter of a task changes (for example it timed out or
+got a signal), the priority of the owner task is readjusted. [The
+priority enqueueing is handled by "plists", see include/linux/plist.h
+for more details.]
+
+RT-mutexes are optimized for fastpath operations and have no internal
+locking overhead when locking an uncontended mutex or unlocking a mutex
+without waiters. The optimized fastpath operations require cmpxchg
+support. [If that is not available then the rt-mutex internal spinlock
+is used]
+
+The state of the rt-mutex is tracked via the owner field of the rt-mutex
+structure:
+
+rt_mutex->owner holds the task_struct pointer of the owner. Bit 0 and 1
+are used to keep track of the "owner is pending" and "rtmutex has
+waiters" state.
+
+ owner bit1 bit0
+ NULL 0 0 mutex is free (fast acquire possible)
+ NULL 0 1 invalid state
+ NULL 1 0 invalid state
+ NULL 1 1 invalid state
+ taskpointer 0 0 mutex is held (fast release possible)
+ taskpointer 0 1 task is pending owner
+ taskpointer 1 0 mutex is held and has waiters
+ taskpointer 1 1 task is pending owner and mutex has waiters
+
+Pending-ownership handling is a performance optimization:
+pending-ownership is assigned to the first (highest priority) waiter of
+the mutex, when the mutex is released. The thread is woken up and once
+it starts executing it can acquire the mutex. Until the mutex is taken
+by it (bit 0 is cleared) a competing higher priority thread can "steal"
+the mutex which puts the woken up thread back on the waiters list.
+
+The pending-ownership optimization is especially important for the
+uninterrupted workflow of high-prio tasks which repeatedly
+takes/releases locks that have lower-prio waiters. Without this
+optimization the higher-prio thread would ping-pong to the lower-prio
+task [because at unlock time we always assign a new owner].
Index: linux-pi-futex.mm.q/Documentation/rtmutex.txt
===================================================================
--- linux-pi-futex.mm.q.orig/Documentation/rtmutex.txt
+++ /dev/null
@@ -1,60 +0,0 @@
-RT Mutex Subsystem with PI support
-
-RT Mutexes with priority inheritance are used to support pthread_mutexes
-with priority inheritance attributes.
-
-The basic technology was developed in the preempt-rt tree and
-streamlined for the pthread_mutex support.
-
-RT Mutexes extend the semantics of Mutexes by the priority inheritance
-protocol. Sharing code and data structures with the Mutex code is not
-feasible due to the extended requirements of RT Mutexes.
-
-Basic operation principle:
-
-A low priority owner of a rt_mutex inherits the priority of a higher
-priority waiter until the mutex is released. Is the temporary priority
-boosted owner blocked on a rt_mutex itself it propagates the priority
-boosting to the owner of the rt_mutex it is blocked on. The priority
-boosting is immidiately removed once the rt_mutex has been unlocked.
-This technology allows to shorten the blocking on mutexes which
-protect shared resources. Priority inheritance is not a magic bullet
-for poorly designed applications, but allows optimizations in cases
-where the protection of shared resources might affect critical parts
-of an high priority thread.
-
-The enqueueing of the waiters into the rtmutex waiter list is done in
-priority order. In case of the same priority FIFO order is chosen. Per
-rtmutex only the top priority waiter is enqueued into the owners
-priority waiters list. Also this list enqueues in priority
-order. Whenever the top priority waiter of a task is changed the
-priority of the task is readjusted. The priority enqueueing is handled
-by plists, see also include/linux/plist.h for further explanation.
-
-RT Mutexes are optimized for fastpath operations and have no runtime
-overhead in case of locking an uncontended mutex or unlocking a mutex
-without waiters. The optimized fathpath operations require cmpxchg
-support.
-
-The state of the rtmutex is tracked via the owner field of the
-rt_mutex structure:
-
-rt_mutex->owner holds the task_struct pointer of the owner. Bit 0 and
-1 are used to keep track of the "owner is pending" and "rtmutex has
-waiters" state.
-
-owner bit1 bit0
-NULL 0 0 mutex is free (fast acquire possible)
-NULL 0 1 invalid state
-NULL 1 0 invalid state
-NULL 1 1 invalid state
-taskpointer 0 0 mutex is held (fast release possible)
-taskpointer 0 1 task is pending owner
-taskpointer 1 0 mutex is held and has waiters
-taskpointer 1 1 task is pending owner and mutex has more waiters
-
-Pending ownership is assigned to the first (highest priority) waiter
-of the mutex, when the mutex is released. The thread is woken up and
-can now acquire the mutex. Until the mutex is taken (bit 0 cleared) a
-competing higher priority thread can steal the mutex which puts the
-woken up thread back on the waiters list.
Index: linux-pi-futex.mm.q/include/linux/futex.h
===================================================================
--- linux-pi-futex.mm.q.orig/include/linux/futex.h
+++ linux-pi-futex.mm.q/include/linux/futex.h
@@ -14,6 +14,7 @@
#define FUTEX_WAKE_OP 5
#define FUTEX_LOCK_PI 6
#define FUTEX_UNLOCK_PI 7
+#define FUTEX_TRYLOCK_PI 8
/*
* Support for robust futexes: the kernel cleans up held futexes at
Index: linux-pi-futex.mm.q/include/linux/rtmutex.h
===================================================================
--- linux-pi-futex.mm.q.orig/include/linux/rtmutex.h
+++ linux-pi-futex.mm.q/include/linux/rtmutex.h
@@ -29,7 +29,7 @@ struct rt_mutex {
struct task_struct *owner;
#ifdef CONFIG_DEBUG_RT_MUTEXES
int save_state;
- struct list_head held_list;
+ struct list_head held_list_entry;
unsigned long acquire_ip;
const char *name, *file;
int line;
@@ -66,7 +66,7 @@ struct hrtimer_sleeper;
#define __RT_MUTEX_INITIALIZER(mutexname) \
{ .wait_lock = SPIN_LOCK_UNLOCKED \
- , .wait_list = PLIST_HEAD_INIT(mutexname.wait_list) \
+ , .wait_list = PLIST_HEAD_INIT(mutexname.wait_list, mutexname.wait_lock) \
, .owner = NULL \
__DEBUG_RT_MUTEX_INITIALIZER(mutexname)}
@@ -98,11 +98,19 @@ extern int rt_mutex_trylock(struct rt_mu
extern void rt_mutex_unlock(struct rt_mutex *lock);
+#ifdef CONFIG_DEBUG_RT_MUTEXES
+# define INIT_RT_MUTEX_DEBUG(tsk) \
+ .held_list_head = LIST_HEAD_INIT(tsk.held_list_head), \
+ .held_list_lock = SPIN_LOCK_UNLOCKED
+#else
+# define INIT_RT_MUTEX_DEBUG(tsk)
+#endif
+
#ifdef CONFIG_RT_MUTEXES
# define INIT_RT_MUTEXES(tsk) \
- .pi_waiters = PLIST_HEAD_INIT(tsk.pi_waiters), \
+ .pi_waiters = PLIST_HEAD_INIT(tsk.pi_waiters, tsk.pi_lock), \
.pi_lock = SPIN_LOCK_UNLOCKED, \
- .pi_lock_chain = LIST_HEAD_INIT(tsk.pi_lock_chain),
+ INIT_RT_MUTEX_DEBUG(tsk)
#else
# define INIT_RT_MUTEXES(tsk)
#endif
Index: linux-pi-futex.mm.q/include/linux/sched.h
===================================================================
--- linux-pi-futex.mm.q.orig/include/linux/sched.h
+++ linux-pi-futex.mm.q/include/linux/sched.h
@@ -865,9 +865,10 @@ struct task_struct {
struct plist_head pi_waiters;
/* Deadlock detection and priority inheritance handling */
struct rt_mutex_waiter *pi_blocked_on;
- /* PI locking helpers */
- struct task_struct *pi_locked_by;
- struct list_head pi_lock_chain;
+# ifdef CONFIG_DEBUG_RT_MUTEXES
+ spinlock_t held_list_lock;
+ struct list_head held_list_head;
+# endif
#endif
#ifdef CONFIG_DEBUG_MUTEXES
@@ -984,7 +985,7 @@ static inline void put_task_struct(struc
#define PF_SPREAD_PAGE 0x04000000 /* Spread page cache over cpuset */
#define PF_SPREAD_SLAB 0x08000000 /* Spread some slab caches over cpuset */
#define PF_MEMPOLICY 0x10000000 /* Non-default NUMA mempolicy */
-#define PF_MUTEX_TESTER 0x20000000 /* Thread belongs to the rt mutex tester */
+#define PF_MUTEX_TESTER 0x02000000 /* Thread belongs to the rt mutex tester */
/*
* Only the _current_ task can read/write to tsk->flags, but other
Index: linux-pi-futex.mm.q/include/linux/sysctl.h
===================================================================
--- linux-pi-futex.mm.q.orig/include/linux/sysctl.h
+++ linux-pi-futex.mm.q/include/linux/sysctl.h
@@ -148,6 +148,7 @@ enum
KERN_SPIN_RETRY=70, /* int: number of spinlock retries */
KERN_ACPI_VIDEO_FLAGS=71, /* int: flags for setting up video after ACPI sleep */
KERN_IA64_UNALIGNED=72, /* int: ia64 unaligned userland trap enable */
+ KERN_MAX_LOCK_DEPTH=73
};
Index: linux-pi-futex.mm.q/kernel/fork.c
===================================================================
--- linux-pi-futex.mm.q.orig/kernel/fork.c
+++ linux-pi-futex.mm.q/kernel/fork.c
@@ -926,10 +926,12 @@ static inline void rt_mutex_init_task(st
{
#ifdef CONFIG_RT_MUTEXES
spin_lock_init(&p->pi_lock);
- plist_head_init(&p->pi_waiters);
+ plist_head_init(&p->pi_waiters, &p->pi_lock);
p->pi_blocked_on = NULL;
- p->pi_locked_by = NULL;
- INIT_LIST_HEAD(&p->pi_lock_chain);
+# ifdef CONFIG_DEBUG_RT_MUTEXES
+ spin_lock_init(&p->held_list_lock);
+ INIT_LIST_HEAD(&p->held_list_head);
+# endif
#endif
}
Index: linux-pi-futex.mm.q/kernel/futex.c
===================================================================
--- linux-pi-futex.mm.q.orig/kernel/futex.c
+++ linux-pi-futex.mm.q/kernel/futex.c
@@ -480,6 +480,7 @@ lookup_pi_state(u32 uval, struct futex_h
return 0;
}
}
+
/*
* We are the first waiter - try to look up the real owner and
* attach the new pi_state to it:
@@ -930,9 +931,7 @@ static int unqueue_me(struct futex_q *q)
WARN_ON(list_empty(&q->list));
list_del(&q->list);
- if (q->pi_state)
- free_pi_state(q->pi_state);
- q->pi_state = NULL;
+ BUG_ON(q->pi_state);
spin_unlock(lock_ptr);
ret = 1;
@@ -942,6 +941,24 @@ static int unqueue_me(struct futex_q *q)
return ret;
}
+/*
+ * PI futexes can not be requeued and must remove themself from the
+ * hash bucket. The hash bucket lock is held on entry and dropped here.
+ */
+static void unqueue_me_pi(struct futex_q *q, struct futex_hash_bucket *hb)
+{
+ WARN_ON(list_empty(&q->list));
+ list_del(&q->list);
+
+ BUG_ON(!q->pi_state);
+ free_pi_state(q->pi_state);
+ q->pi_state = NULL;
+
+ spin_unlock(&hb->lock);
+
+ drop_key_refs(&q->key);
+}
+
static int futex_wait(u32 __user *uaddr, u32 val, unsigned long time)
{
struct task_struct *curr = current;
@@ -1062,7 +1079,7 @@ static int futex_wait(u32 __user *uaddr,
* races the kernel might see a 0 value of the futex too.)
*/
static int futex_lock_pi(u32 __user *uaddr, int detect,
- unsigned long sec, long nsec)
+ unsigned long sec, long nsec, int trylock)
{
struct task_struct *curr = current;
struct futex_hash_bucket *hb;
@@ -1138,8 +1155,32 @@ static int futex_lock_pi(u32 __user *uad
* we are the first waiter):
*/
ret = lookup_pi_state(uval, hb, &q);
- if (unlikely(ret))
+
+ if (unlikely(ret)) {
+ /*
+ * There were no waiters and the owner task lookup
+ * failed. When the OWNER_DIED bit is set, then we
+ * know that this is a robust futex and we actually
+ * take the lock. This is safe as we are protected by
+ * the hash bucket lock.
+ */
+ if (curval & FUTEX_OWNER_DIED) {
+ uval = newval;
+ newval = current->pid | FUTEX_OWNER_DIED;
+
+ inc_preempt_count();
+ curval = futex_atomic_cmpxchg_inatomic(uaddr,
+ uval, newval);
+ dec_preempt_count();
+
+ if (unlikely(curval == -EFAULT))
+ goto uaddr_faulted;
+ if (unlikely(curval != uval))
+ goto retry_locked;
+ ret = 0;
+ }
goto out_unlock_release_sem;
+ }
/*
* Only actually queue now that the atomic ops are done:
@@ -1156,7 +1197,16 @@ static int futex_lock_pi(u32 __user *uad
/*
* Block on the PI mutex:
*/
- ret = rt_mutex_timed_lock(&q.pi_state->pi_mutex, to, 1);
+ if (!trylock)
+ ret = rt_mutex_timed_lock(&q.pi_state->pi_mutex, to, 1);
+ else {
+ ret = rt_mutex_trylock(&q.pi_state->pi_mutex);
+ /* Fixup the trylock return value: */
+ ret = ret ? 0 : -EWOULDBLOCK;
+ }
+
+ down_read(&curr->mm->mmap_sem);
+ hb = queue_lock(&q, -1, NULL);
/*
* Got the lock. We might not be the anticipated owner if we
@@ -1165,9 +1215,6 @@ static int futex_lock_pi(u32 __user *uad
if (!ret && q.pi_state->owner != curr) {
u32 newtid = current->pid | FUTEX_WAITERS;
- down_read(&curr->mm->mmap_sem);
- hb = queue_lock(&q, -1, NULL);
-
/* Owner died? */
if (q.pi_state->owner != NULL) {
spin_lock(&q.pi_state->owner->pi_lock);
@@ -1182,7 +1229,8 @@ static int futex_lock_pi(u32 __user *uad
list_add(&q.pi_state->list, ¤t->pi_state_list);
spin_unlock(¤t->pi_lock);
- queue_unlock(&q, hb);
+ /* Unqueue and drop the lock */
+ unqueue_me_pi(&q, hb);
up_read(&curr->mm->mmap_sem);
/*
* We own it, so we have to replace the pending owner
@@ -1200,10 +1248,21 @@ static int futex_lock_pi(u32 __user *uad
break;
uval = curval;
}
+ } else {
+ /*
+ * Catch the rare case, where the lock was released
+ * when we were on the way back before we locked
+ * the hash bucket.
+ */
+ if (ret && q.pi_state->owner == curr) {
+ if (rt_mutex_trylock(&q.pi_state->pi_mutex))
+ ret = 0;
+ }
+ /* Unqueue and drop the lock */
+ unqueue_me_pi(&q, hb);
+ up_read(&curr->mm->mmap_sem);
}
- unqueue_me(&q);
-
if (!detect && ret == -EDEADLK && 0)
force_sig(SIGKILL, current);
@@ -1652,11 +1711,14 @@ long do_futex(u32 __user *uaddr, int op,
ret = futex_wake_op(uaddr, uaddr2, val, val2, val3);
break;
case FUTEX_LOCK_PI:
- ret = futex_lock_pi(uaddr, val, timeout, val2);
+ ret = futex_lock_pi(uaddr, val, timeout, val2, 0);
break;
case FUTEX_UNLOCK_PI:
ret = futex_unlock_pi(uaddr);
break;
+ case FUTEX_TRYLOCK_PI:
+ ret = futex_lock_pi(uaddr, 0, timeout, val2, 1);
+ break;
default:
ret = -ENOSYS;
}
Index: linux-pi-futex.mm.q/kernel/rtmutex-debug.c
===================================================================
--- linux-pi-futex.mm.q.orig/kernel/rtmutex-debug.c
+++ linux-pi-futex.mm.q/kernel/rtmutex-debug.c
@@ -45,7 +45,8 @@ do { \
console_verbose(); \
if (spin_is_locked(¤t->pi_lock)) \
spin_unlock(¤t->pi_lock); \
- spin_unlock(&tracelock); \
+ if (spin_is_locked(¤t->held_list_lock)) \
+ spin_unlock(¤t->held_list_lock); \
} \
} while (0)
@@ -83,14 +84,6 @@ do { \
# define SMP_TRACE_BUG_ON_LOCKED(c) do { } while (0)
#endif
-
-/*
- * We need a global lock when we walk through the multi-process
- * lock tree...
- */
-static spinlock_t tracelock = SPIN_LOCK_UNLOCKED;
-static LIST_HEAD(held_locks);
-
/*
* deadlock detection flag. We turn it off when we detect
* the first problem because we dont want to recurse back
@@ -183,7 +176,7 @@ static void show_task_locks(task_t *p)
printk(" (not blocked)\n");
}
-void rt_mutex_show_held_locks(task_t *filter)
+void rt_mutex_show_held_locks(task_t *task, int verbose)
{
struct list_head *curr, *cursor = NULL;
struct rt_mutex *lock;
@@ -194,41 +187,32 @@ void rt_mutex_show_held_locks(task_t *fi
if (!rt_trace_on)
return;
- if (filter) {
+ if (verbose) {
printk("------------------------------\n");
printk("| showing all locks held by: | (");
- printk_task_short(filter);
+ printk_task_short(task);
printk("):\n");
printk("------------------------------\n");
- } else {
- printk("---------------------------\n");
- printk("| showing all locks held: |\n");
- printk("---------------------------\n");
}
- /*
- * Play safe and acquire the global trace lock. We
- * cannot printk with that lock held so we iterate
- * very carefully:
- */
next:
- spin_lock_irqsave(&tracelock, flags);
- list_for_each(curr, &held_locks) {
+ spin_lock_irqsave(&task->held_list_lock, flags);
+ list_for_each(curr, &task->held_list_head) {
if (cursor && curr != cursor)
continue;
- lock = list_entry(curr, struct rt_mutex, held_list);
+ lock = list_entry(curr, struct rt_mutex, held_list_entry);
t = rt_mutex_owner(lock);
- if (filter && (t != filter))
- continue;
+ WARN_ON(t != task);
count++;
cursor = curr->next;
- spin_unlock_irqrestore(&tracelock, flags);
+ spin_unlock_irqrestore(&task->held_list_lock, flags);
printk("\n#%03d: ", count);
- printk_lock(lock, filter ? 0 : 1);
+ printk_lock(lock, 0);
goto next;
}
- spin_unlock_irqrestore(&tracelock, flags);
+ spin_unlock_irqrestore(&task->held_list_lock, flags);
+
printk("\n");
}
@@ -238,7 +222,10 @@ void rt_mutex_show_all_locks(void)
int count = 10;
int unlock = 1;
- printk("\nshowing all tasks:\n");
+ printk("\n");
+ printk("----------------------\n");
+ printk("| showing all tasks: |\n");
+ printk("----------------------\n");
/*
* Here we try to get the tasklist_lock as hard as possible,
@@ -270,7 +257,19 @@ retry:
} while_each_thread(g, p);
printk("\n");
- rt_mutex_show_held_locks(NULL);
+
+ printk("-----------------------------------------\n");
+ printk("| showing all locks held in the system: |\n");
+ printk("-----------------------------------------\n");
+
+ do_each_thread(g, p) {
+ rt_mutex_show_held_locks(p, 0);
+ if (!unlock)
+ if (read_trylock(&tasklist_lock))
+ unlock = 1;
+ } while_each_thread(g, p);
+
+
printk("=============================================\n\n");
if (unlock)
@@ -279,10 +278,9 @@ retry:
void rt_mutex_debug_check_no_locks_held(task_t *task)
{
- struct list_head *curr, *next, *cursor = NULL;
- struct rt_mutex *lock;
struct rt_mutex_waiter *w;
- unsigned long flags;
+ struct list_head *curr;
+ struct rt_mutex *lock;
if (!rt_trace_on)
return;
@@ -291,25 +289,9 @@ void rt_mutex_debug_check_no_locks_held(
printk_task(task);
printk("\n");
}
-restart:
- spin_lock_irqsave(&tracelock, flags);
- list_for_each_safe(curr, next, &held_locks) {
- if (cursor && curr != cursor)
- continue;
- lock = list_entry(curr, struct rt_mutex, held_list);
- if(task != rt_mutex_owner(lock))
- continue;
- cursor = next;
- list_del_init(curr);
- spin_unlock_irqrestore(&tracelock, flags);
+ if (list_empty(&task->held_list_head))
+ return;
- printk("BUG: %s/%d, lock held at task exit time!\n",
- task->comm, task->pid);
- printk_lock(lock, 1);
- if (rt_mutex_owner(lock) != task)
- printk("exiting task is not even the owner??\n");
- goto restart;
- }
spin_lock(&task->pi_lock);
plist_for_each_entry(w, &task->pi_waiters, pi_list_entry) {
TRACE_OFF();
@@ -320,33 +302,36 @@ restart:
return;
}
spin_unlock(&task->pi_lock);
- spin_unlock_irqrestore(&tracelock, flags);
+
+ list_for_each(curr, &task->held_list_head) {
+ lock = list_entry(curr, struct rt_mutex, held_list_entry);
+
+ printk("BUG: %s/%d, lock held at task exit time!\n",
+ task->comm, task->pid);
+ printk_lock(lock, 1);
+ if (rt_mutex_owner(lock) != task)
+ printk("exiting task is not even the owner??\n");
+ }
}
int rt_mutex_debug_check_no_locks_freed(const void *from, unsigned long len)
{
- struct list_head *curr, *next, *cursor = NULL;
const void *to = from + len;
+ struct list_head *curr;
struct rt_mutex *lock;
unsigned long flags;
void *lock_addr;
- int err = 0;
if (!rt_trace_on)
- return err;
-restart:
- spin_lock_irqsave(&tracelock, flags);
- list_for_each_safe(curr, next, &held_locks) {
- if (cursor && curr != cursor)
- continue;
- lock = list_entry(curr, struct rt_mutex, held_list);
+ return 0;
+
+ spin_lock_irqsave(¤t->held_list_lock, flags);
+ list_for_each(curr, ¤t->held_list_head) {
+ lock = list_entry(curr, struct rt_mutex, held_list_entry);
lock_addr = lock;
if (lock_addr < from || lock_addr >= to)
continue;
- cursor = next;
- list_del_init(curr);
TRACE_OFF();
- err = 1;
printk("BUG: %s/%d, active lock [%p(%p-%p)] freed!\n",
current->comm, current->pid, lock, from, to);
@@ -354,19 +339,17 @@ restart:
printk_lock(lock, 1);
if (rt_mutex_owner(lock) != current)
printk("freeing task is not even the owner??\n");
- goto restart;
+ return 1;
}
- spin_unlock_irqrestore(&tracelock, flags);
+ spin_unlock_irqrestore(¤t->held_list_lock, flags);
- return err;
+ return 0;
}
-void rt_mutex_debug_task_free(struct task_struct *tsk)
+void rt_mutex_debug_task_free(struct task_struct *task)
{
- WARN_ON(!plist_head_empty(&tsk->pi_waiters));
- WARN_ON(!list_empty(&tsk->pi_lock_chain));
- WARN_ON(tsk->pi_blocked_on);
- WARN_ON(tsk->pi_locked_by);
+ WARN_ON(!plist_head_empty(&task->pi_waiters));
+ WARN_ON(task->pi_blocked_on);
}
/*
@@ -383,9 +366,10 @@ void debug_rt_mutex_deadlock(int detect,
return;
task = rt_mutex_owner(act_waiter->lock);
-
- act_waiter->deadlock_task_pid = task->pid;
- act_waiter->deadlock_lock = lock;
+ if (task && task != current) {
+ act_waiter->deadlock_task_pid = task->pid;
+ act_waiter->deadlock_lock = lock;
+ }
}
void debug_rt_mutex_print_deadlock(struct rt_mutex_waiter *waiter)
@@ -417,8 +401,8 @@ void debug_rt_mutex_print_deadlock(struc
printk("\n2) %s/%d is blocked on this lock:\n", task->comm, task->pid);
printk_lock(waiter->deadlock_lock, 1);
- rt_mutex_show_held_locks(current);
- rt_mutex_show_held_locks(task);
+ rt_mutex_show_held_locks(current, 1);
+ rt_mutex_show_held_locks(task, 1);
printk("\n%s/%d's [blocked] stackdump:\n\n", task->comm, task->pid);
show_stack(task, NULL);
@@ -436,11 +420,11 @@ void debug_rt_mutex_lock(struct rt_mutex
unsigned long flags;
if (rt_trace_on) {
- TRACE_WARN_ON_LOCKED(!list_empty(&lock->held_list));
+ TRACE_WARN_ON_LOCKED(!list_empty(&lock->held_list_entry));
- spin_lock_irqsave(&tracelock, flags);
- list_add_tail(&lock->held_list, &held_locks);
- spin_unlock_irqrestore(&tracelock, flags);
+ spin_lock_irqsave(¤t->held_list_lock, flags);
+ list_add_tail(&lock->held_list_entry, ¤t->held_list_head);
+ spin_unlock_irqrestore(¤t->held_list_lock, flags);
lock->acquire_ip = ip;
}
@@ -452,11 +436,27 @@ void debug_rt_mutex_unlock(struct rt_mut
if (rt_trace_on) {
TRACE_WARN_ON_LOCKED(rt_mutex_owner(lock) != current);
- TRACE_WARN_ON_LOCKED(list_empty(&lock->held_list));
+ TRACE_WARN_ON_LOCKED(list_empty(&lock->held_list_entry));
- spin_lock_irqsave(&tracelock, flags);
- list_del_init(&lock->held_list);
- spin_unlock_irqrestore(&tracelock, flags);
+ spin_lock_irqsave(¤t->held_list_lock, flags);
+ list_del_init(&lock->held_list_entry);
+ spin_unlock_irqrestore(¤t->held_list_lock, flags);
+ }
+}
+
+void debug_rt_mutex_proxy_lock(struct rt_mutex *lock,
+ struct task_struct *powner __IP_DECL__)
+{
+ unsigned long flags;
+
+ if (rt_trace_on) {
+ TRACE_WARN_ON_LOCKED(!list_empty(&lock->held_list_entry));
+
+ spin_lock_irqsave(&powner->held_list_lock, flags);
+ list_add_tail(&lock->held_list_entry, &powner->held_list_head);
+ spin_unlock_irqrestore(&powner->held_list_lock, flags);
+
+ lock->acquire_ip = ip;
}
}
@@ -465,12 +465,14 @@ void debug_rt_mutex_proxy_unlock(struct
unsigned long flags;
if (rt_trace_on) {
- TRACE_WARN_ON_LOCKED(!rt_mutex_owner(lock));
- TRACE_WARN_ON_LOCKED(list_empty(&lock->held_list));
+ struct task_struct *owner = rt_mutex_owner(lock);
+
+ TRACE_WARN_ON_LOCKED(!owner);
+ TRACE_WARN_ON_LOCKED(list_empty(&lock->held_list_entry));
- spin_lock_irqsave(&tracelock, flags);
- list_del_init(&lock->held_list);
- spin_unlock_irqrestore(&tracelock, flags);
+ spin_lock_irqsave(&owner->held_list_lock, flags);
+ list_del_init(&lock->held_list_entry);
+ spin_unlock_irqrestore(&owner->held_list_lock, flags);
}
}
@@ -496,7 +498,7 @@ void debug_rt_mutex_init(struct rt_mutex
if (rt_trace_on) {
rt_mutex_debug_check_no_locks_freed(addr,
sizeof(struct rt_mutex));
- INIT_LIST_HEAD(&lock->held_list);
+ INIT_LIST_HEAD(&lock->held_list_entry);
lock->name = name;
}
}
Index: linux-pi-futex.mm.q/kernel/rtmutex-debug.h
===================================================================
--- linux-pi-futex.mm.q.orig/kernel/rtmutex-debug.h
+++ linux-pi-futex.mm.q/kernel/rtmutex-debug.h
@@ -21,10 +21,17 @@ extern void debug_rt_mutex_free_waiter(s
extern void debug_rt_mutex_init(struct rt_mutex *lock, const char *name);
extern void debug_rt_mutex_lock(struct rt_mutex *lock __IP_DECL__);
extern void debug_rt_mutex_unlock(struct rt_mutex *lock);
+extern void debug_rt_mutex_proxy_lock(struct rt_mutex *lock,
+ struct task_struct *powner __IP_DECL__);
extern void debug_rt_mutex_proxy_unlock(struct rt_mutex *lock);
extern void debug_rt_mutex_deadlock(int detect, struct rt_mutex_waiter *waiter,
struct rt_mutex *lock);
extern void debug_rt_mutex_print_deadlock(struct rt_mutex_waiter *waiter);
-# define debug_rt_mutex_detect_deadlock(d) (1)
# define debug_rt_mutex_reset_waiter(w) \
do { (w)->deadlock_lock = NULL; } while (0)
+
+static inline int debug_rt_mutex_detect_deadlock(struct rt_mutex_waiter *waiter,
+ int detect)
+{
+ return (waiter != NULL);
+}
Index: linux-pi-futex.mm.q/kernel/rtmutex.c
===================================================================
--- linux-pi-futex.mm.q.orig/kernel/rtmutex.c
+++ linux-pi-futex.mm.q/kernel/rtmutex.c
@@ -1,11 +1,12 @@
/*
* RT-Mutexes: simple blocking mutual exclusion locks with PI support
*
- * started by Ingo Molnar and Thomas Gleixner:
+ * started by Ingo Molnar and Thomas Gleixner.
*
* Copyright (C) 2004-2006 Red Hat, Inc., Ingo Molnar <mingo@redhat.com>
- * Copyright (C) 2006 Timesys Corp., Thomas Gleixner <tglx@timesys.com>
+ * Copyright (C) 2005-2006 Timesys Corp., Thomas Gleixner <tglx@timesys.com>
* Copyright (C) 2005 Kihon Technologies Inc., Steven Rostedt
+ * Copyright (C) 2006 Esben Nielsen
*/
#include <linux/spinlock.h>
#include <linux/module.h>
@@ -133,211 +134,148 @@ static void __rt_mutex_adjust_prio(struc
*/
static void rt_mutex_adjust_prio(struct task_struct *task)
{
- unsigned long flags;
-
- spin_lock_irqsave(&task->pi_lock, flags);
+ spin_lock(&task->pi_lock);
__rt_mutex_adjust_prio(task);
- spin_unlock_irqrestore(&task->pi_lock, flags);
+ spin_unlock(&task->pi_lock);
}
/*
- * PI-locking: we lock PI-dependencies opportunistically via trylock.
- *
- * In the overwhelming majority of cases the 'PI chain' is empty or at
- * most 1-2 entries long, for which the trylock is sufficient,
- * scalability-wise. The locking might look a bit scary, for which we
- * apologize in advance :-)
- *
- * If any of the trylocks fails then we back out, task the global
- * pi_conflicts_lock and take the locks again. This ensures deadlock-free
- * but still scalable locking in the dependency graph, combined with
- * the ability to reliably (and cheaply) detect user-space deadlocks.
+ * Max number of times we'll walk the boosting chain:
*/
-static DEFINE_SPINLOCK(pi_conflicts_lock);
+int max_lock_depth = 1024;
/*
- * Lock the full boosting chain.
- *
- * If 'try' is set, we have to backout if we hit a owner who is
- * running its own pi chain operation. We go back and take the slow
- * path via the pi_conflicts_lock.
- *
- * We put all held locks into a list, via ->pi_lock_chain, and walk
- * this list at unlock_pi_chain() time.
- */
-static int lock_pi_chain(struct rt_mutex *act_lock,
- struct rt_mutex_waiter *waiter,
- struct list_head *lock_chain,
- int try, int detect_deadlock)
-{
- struct task_struct *owner;
- struct rt_mutex *nextlock, *lock = act_lock;
- struct rt_mutex_waiter *nextwaiter;
- int deadlock_detect;
+ * Adjust the priority chain. Also used for deadlock detection.
+ * Decreases task's usage by one - may thus free the task.
+ * Returns 0 or -EDEADLK.
+ */
+static int rt_mutex_adjust_prio_chain(task_t *task,
+ int deadlock_detect,
+ struct rt_mutex *orig_lock,
+ struct rt_mutex_waiter *orig_waiter
+ __IP_DECL__)
+{
+ struct rt_mutex *lock;
+ struct rt_mutex_waiter *waiter, *top_waiter = orig_waiter;
+ int detect_deadlock, ret = 0, depth = 0;
+
+ detect_deadlock = debug_rt_mutex_detect_deadlock(orig_waiter,
+ deadlock_detect);
/*
- * Debugging might turn deadlock detection on, unconditionally:
+ * The (de)boosting is a step by step approach with a lot of
+ * pitfalls. We want this to be preemptible and we want hold a
+ * maximum of two locks per step. So we have to check
+ * carefully whether things change under us.
*/
- deadlock_detect = debug_rt_mutex_detect_deadlock(detect_deadlock);
-
- for (;;) {
- owner = rt_mutex_owner(lock);
-
- /* Check for circular dependencies */
- if (unlikely(owner->pi_locked_by == current)) {
- debug_rt_mutex_deadlock(detect_deadlock, waiter, lock);
- return detect_deadlock ? -EDEADLK : 1;
- }
-
- while (!spin_trylock(&owner->pi_lock)) {
- /*
- * Owner runs its own chain. Go back and take
- * the slow path
- */
- if (try && owner->pi_locked_by == owner)
- return -EBUSY;
- cpu_relax();
- }
-
- BUG_ON(owner->pi_locked_by);
- owner->pi_locked_by = current;
- BUG_ON(!list_empty(&owner->pi_lock_chain));
- list_add(&owner->pi_lock_chain, lock_chain);
+ again:
+ if (++depth > max_lock_depth) {
+ static int prev_max;
/*
- * When the owner is blocked on a lock, try to take
- * the lock:
+ * Print this only once. If the admin changes the limit,
+ * print a new message when reaching the limit again.
*/
- nextwaiter = owner->pi_blocked_on;
-
- /* End of chain? */
- if (!nextwaiter)
- return 1;
-
- nextlock = nextwaiter->lock;
-
- /* Check for circular dependencies: */
- if (unlikely(nextlock == act_lock ||
- rt_mutex_owner(nextlock) == current)) {
- debug_rt_mutex_deadlock(detect_deadlock, waiter,
- nextlock);
- list_del_init(&owner->pi_lock_chain);
- owner->pi_locked_by = NULL;
- spin_unlock(&owner->pi_lock);
- return detect_deadlock ? -EDEADLK : 1;
+ if (prev_max != max_lock_depth) {
+ prev_max = max_lock_depth;
+ printk(KERN_WARNING "Maximum lock depth %d reached "
+ "task: %s (%d)\n", max_lock_depth,
+ task->comm, task->pid);
}
+ put_task_struct(task);
- /* Try to get nextlock->wait_lock: */
- if (unlikely(!spin_trylock(&nextlock->wait_lock))) {
- list_del_init(&owner->pi_lock_chain);
- owner->pi_locked_by = NULL;
- spin_unlock(&owner->pi_lock);
- cpu_relax();
- continue;
- }
-
- lock = nextlock;
+ return deadlock_detect ? -EDEADLK : 0;
+ }
+ retry:
+ /*
+ * Task can not go away as we did a get_task() before !
+ */
+ spin_lock(&task->pi_lock);
- /*
- * If deadlock detection is done (or has to be done, as
- * for userspace locks), we have to walk the full chain
- * unconditionally.
- */
- if (deadlock_detect)
- continue;
+ waiter = task->pi_blocked_on;
+ /*
+ * Check whether the end of the boosting chain has been
+ * reached or the state of the chain has changed while we
+ * dropped the locks.
+ */
+ if (!waiter || !waiter->task)
+ goto out_unlock_pi;
- /*
- * Optimization: we only have to continue up to the point
- * where boosting/unboosting still has to be done:
- */
+ if (top_waiter && (!task_has_pi_waiters(task) ||
+ top_waiter != task_top_pi_waiter(task)))
+ goto out_unlock_pi;
- /* Boost or unboost? */
- if (waiter) {
- /* If the top waiter has higher priority, stop: */
- if (rt_mutex_top_waiter(lock)->list_entry.prio <=
- waiter->list_entry.prio)
- return 1;
- } else {
- /* If nextwaiter is not the top waiter, stop: */
- if (rt_mutex_top_waiter(lock) != nextwaiter)
- return 1;
- }
+ /*
+ * When deadlock detection is off then we check, if further
+ * priority adjustment is necessary.
+ */
+ if (!detect_deadlock && waiter->list_entry.prio == task->prio) {
+ BUG_ON(waiter->pi_list_entry.prio != waiter->list_entry.prio);
+ goto out_unlock_pi;
}
-}
-
-/*
- * Unlock the pi_chain:
- */
-static void unlock_pi_chain(struct list_head *lock_chain)
-{
- struct task_struct *owner, *tmp;
- list_for_each_entry_safe(owner, tmp, lock_chain, pi_lock_chain) {
- struct rt_mutex_waiter *waiter = owner->pi_blocked_on;
-
- list_del_init(&owner->pi_lock_chain);
- BUG_ON(!owner->pi_locked_by);
- owner->pi_locked_by = NULL;
- if (waiter)
- spin_unlock(&waiter->lock->wait_lock);
- spin_unlock(&owner->pi_lock);
+ lock = waiter->lock;
+ if (!spin_trylock(&lock->wait_lock)) {
+ spin_unlock(&task->pi_lock);
+ cpu_relax();
+ goto retry;
}
-}
-/*
- * Do the priority (un)boosting along the chain:
- */
-static void adjust_pi_chain(struct rt_mutex *lock,
- struct rt_mutex_waiter *waiter,
- struct rt_mutex_waiter *top_waiter,
- struct list_head *lock_chain)
-{
- struct task_struct *owner = rt_mutex_owner(lock);
- struct list_head *curr = lock_chain->prev;
+ /* Deadlock detection */
+ if (lock == orig_lock || rt_mutex_owner(lock) == current) {
+ debug_rt_mutex_deadlock(deadlock_detect, orig_waiter, lock);
+ spin_unlock(&lock->wait_lock);
+ ret = deadlock_detect ? -EDEADLK : 0;
+ goto out_unlock_pi;
+ }
- for (;;) {
- if (top_waiter)
- plist_del(&top_waiter->pi_list_entry,
- &owner->pi_waiters);
+ top_waiter = rt_mutex_top_waiter(lock);
- if (waiter)
- waiter->pi_list_entry.prio = waiter->task->prio;
+ /* Requeue the waiter */
+ plist_del(&waiter->list_entry, &lock->wait_list);
+ waiter->list_entry.prio = task->prio;
+ plist_add(&waiter->list_entry, &lock->wait_list);
- if (rt_mutex_has_waiters(lock)) {
- top_waiter = rt_mutex_top_waiter(lock);
- plist_add(&top_waiter->pi_list_entry,
- &owner->pi_waiters);
- }
+ /* Release the task */
+ spin_unlock(&task->pi_lock);
+ put_task_struct(task);
+
+ /* Grab the next task */
+ task = rt_mutex_owner(lock);
+ spin_lock(&task->pi_lock);
+
+ if (waiter == rt_mutex_top_waiter(lock)) {
+ /* Boost the owner */
+ plist_del(&top_waiter->pi_list_entry, &task->pi_waiters);
+ waiter->pi_list_entry.prio = waiter->list_entry.prio;
+ plist_add(&waiter->pi_list_entry, &task->pi_waiters);
+ __rt_mutex_adjust_prio(task);
+
+ } else if (top_waiter == waiter) {
+ /* Deboost the owner */
+ plist_del(&waiter->pi_list_entry, &task->pi_waiters);
+ waiter = rt_mutex_top_waiter(lock);
+ waiter->pi_list_entry.prio = waiter->list_entry.prio;
+ plist_add(&waiter->pi_list_entry, &task->pi_waiters);
+ __rt_mutex_adjust_prio(task);
+ }
- __rt_mutex_adjust_prio(owner);
+ get_task_struct(task);
+ spin_unlock(&task->pi_lock);
- waiter = owner->pi_blocked_on;
- if (!waiter || curr->prev == lock_chain)
- return;
-
- curr = curr->prev;
- lock = waiter->lock;
- owner = rt_mutex_owner(lock);
- top_waiter = rt_mutex_top_waiter(lock);
+ top_waiter = rt_mutex_top_waiter(lock);
+ spin_unlock(&lock->wait_lock);
- plist_del(&waiter->list_entry, &lock->wait_list);
- waiter->list_entry.prio = waiter->task->prio;
- plist_add(&waiter->list_entry, &lock->wait_list);
+ if (!detect_deadlock && waiter != top_waiter)
+ goto out_put_task;
- /*
- * We can stop here, if the waiter is/was not the top
- * priority waiter:
- */
- if (top_waiter != waiter &&
- waiter != rt_mutex_top_waiter(lock))
- return;
+ goto again;
- /*
- * Note: waiter is not necessarily the new top
- * waiter!
- */
- waiter = rt_mutex_top_waiter(lock);
- }
+ out_unlock_pi:
+ spin_unlock(&task->pi_lock);
+ out_put_task:
+ put_task_struct(task);
+ return ret;
}
/*
@@ -448,111 +386,65 @@ static int try_to_take_rt_mutex(struct r
/*
* Task blocks on lock.
*
- * Prepare waiter and potentially propagate our priority into the pi chain.
+ * Prepare waiter and propagate pi chain
*
* This must be called with lock->wait_lock held.
- * return values: 1: waiter queued, 0: got the lock,
- * -EDEADLK: deadlock detected.
*/
static int task_blocks_on_rt_mutex(struct rt_mutex *lock,
struct rt_mutex_waiter *waiter,
- int detect_deadlock __IP_DECL__)
+ int detect_deadlock
+ __IP_DECL__)
{
struct rt_mutex_waiter *top_waiter = waiter;
- LIST_HEAD(lock_chain);
- int res = 1;
+ task_t *owner = rt_mutex_owner(lock);
+ int boost = 0, res;
+ spin_lock(¤t->pi_lock);
+ __rt_mutex_adjust_prio(current);
waiter->task = current;
waiter->lock = lock;
- debug_rt_mutex_reset_waiter(waiter);
-
- spin_lock(¤t->pi_lock);
- current->pi_locked_by = current;
plist_node_init(&waiter->list_entry, current->prio);
plist_node_init(&waiter->pi_list_entry, current->prio);
- /* Get the top priority waiter of the lock: */
+ /* Get the top priority waiter on the lock */
if (rt_mutex_has_waiters(lock))
top_waiter = rt_mutex_top_waiter(lock);
plist_add(&waiter->list_entry, &lock->wait_list);
current->pi_blocked_on = waiter;
- /*
- * Call adjust_prio_chain, when waiter is the new top waiter
- * or when deadlock detection is requested:
- */
- if (waiter != rt_mutex_top_waiter(lock) &&
- !debug_rt_mutex_detect_deadlock(detect_deadlock))
- goto out_unlock_pi;
-
- /* Try to lock the full chain: */
- res = lock_pi_chain(lock, waiter, &lock_chain, 1, detect_deadlock);
-
- if (likely(res == 1))
- adjust_pi_chain(lock, waiter, top_waiter, &lock_chain);
-
- /* Common case: we managed to lock it: */
- if (res != -EBUSY)
- goto out_unlock_chain_pi;
-
- /* Rare case: we hit some other task running a pi chain operation: */
- unlock_pi_chain(&lock_chain);
-
- plist_del(&waiter->list_entry, &lock->wait_list);
- current->pi_blocked_on = NULL;
- current->pi_locked_by = NULL;
spin_unlock(¤t->pi_lock);
- fixup_rt_mutex_waiters(lock);
-
- spin_unlock(&lock->wait_lock);
- /*
- * Here we have dropped all locks, and take the global
- * pi_conflicts_lock. We have to redo all the work, no
- * previous information about the lock is valid anymore:
- */
- spin_lock(&pi_conflicts_lock);
+ if (waiter == rt_mutex_top_waiter(lock)) {
+ spin_lock(&owner->pi_lock);
+ plist_del(&top_waiter->pi_list_entry, &owner->pi_waiters);
+ plist_add(&waiter->pi_list_entry, &owner->pi_waiters);
- spin_lock(&lock->wait_lock);
- if (try_to_take_rt_mutex(lock __IP__)) {
- /*
- * Rare race: against all odds we got the lock.
- */
- res = 0;
- goto out;
+ __rt_mutex_adjust_prio(owner);
+ if (owner->pi_blocked_on) {
+ boost = 1;
+ get_task_struct(owner);
+ }
+ spin_unlock(&owner->pi_lock);
}
+ else if (debug_rt_mutex_detect_deadlock(waiter, detect_deadlock)) {
+ spin_lock(&owner->pi_lock);
+ if (owner->pi_blocked_on) {
+ boost = 1;
+ get_task_struct(owner);
+ }
+ spin_unlock(&owner->pi_lock);
+ }
+ if (!boost)
+ return 0;
- WARN_ON(!rt_mutex_owner(lock) || rt_mutex_owner(lock) == current);
-
- spin_lock(¤t->pi_lock);
- current->pi_locked_by = current;
-
- plist_node_init(&waiter->list_entry, current->prio);
- plist_node_init(&waiter->pi_list_entry, current->prio);
-
- /* Get the top priority waiter of the lock: */
- if (rt_mutex_has_waiters(lock))
- top_waiter = rt_mutex_top_waiter(lock);
- plist_add(&waiter->list_entry, &lock->wait_list);
-
- current->pi_blocked_on = waiter;
-
- /* Lock the full chain: */
- res = lock_pi_chain(lock, waiter, &lock_chain, 0, detect_deadlock);
+ spin_unlock(&lock->wait_lock);
- /* Drop the conflicts lock before adjusting: */
- spin_unlock(&pi_conflicts_lock);
+ res = rt_mutex_adjust_prio_chain(owner, detect_deadlock, lock,
+ waiter __IP__);
- if (likely(res == 1))
- adjust_pi_chain(lock, waiter, top_waiter, &lock_chain);
+ spin_lock(&lock->wait_lock);
- out_unlock_chain_pi:
- unlock_pi_chain(&lock_chain);
- out_unlock_pi:
- current->pi_locked_by = NULL;
- spin_unlock(¤t->pi_lock);
- out:
return res;
}
@@ -569,6 +461,8 @@ static void wakeup_next_waiter(struct rt
struct rt_mutex_waiter *waiter;
struct task_struct *pendowner;
+ spin_lock(¤t->pi_lock);
+
waiter = rt_mutex_top_waiter(lock);
plist_del(&waiter->list_entry, &lock->wait_list);
@@ -578,15 +472,14 @@ static void wakeup_next_waiter(struct rt
* boosted mode and go back to normal after releasing
* lock->wait_lock.
*/
- spin_lock(¤t->pi_lock);
plist_del(&waiter->pi_list_entry, ¤t->pi_waiters);
- spin_unlock(¤t->pi_lock);
-
pendowner = waiter->task;
waiter->task = NULL;
rt_mutex_set_owner(lock, pendowner, RT_MUTEX_OWNER_PENDING);
+ spin_unlock(¤t->pi_lock);
+
/*
* Clear the pi_blocked_on variable and enqueue a possible
* waiter into the pi_waiters list of the pending owner. This
@@ -616,87 +509,52 @@ static void wakeup_next_waiter(struct rt
/*
* Remove a waiter from a lock
*
- * Must be called with lock->wait_lock held.
+ * Must be called with lock->wait_lock held
*/
-static int remove_waiter(struct rt_mutex *lock,
- struct rt_mutex_waiter *waiter __IP_DECL__)
+static void remove_waiter(struct rt_mutex *lock,
+ struct rt_mutex_waiter *waiter __IP_DECL__)
{
- struct rt_mutex_waiter *next_waiter = NULL,
- *top_waiter = rt_mutex_top_waiter(lock);
- LIST_HEAD(lock_chain);
- int res;
-
- plist_del(&waiter->list_entry, &lock->wait_list);
+ int first = (waiter == rt_mutex_top_waiter(lock));
+ int boost = 0;
+ task_t *owner = rt_mutex_owner(lock);
spin_lock(¤t->pi_lock);
-
- if (waiter != top_waiter || rt_mutex_owner(lock) == current)
- goto out;
-
- current->pi_locked_by = current;
-
- if (rt_mutex_has_waiters(lock))
- next_waiter = rt_mutex_top_waiter(lock);
-
- /* Try to lock the full chain: */
- res = lock_pi_chain(lock, next_waiter, &lock_chain, 1, 0);
-
- if (likely(res != -EBUSY)) {
- adjust_pi_chain(lock, next_waiter, waiter, &lock_chain);
- goto out_unlock;
- }
-
- /* We hit some other task running a pi chain operation: */
- unlock_pi_chain(&lock_chain);
- plist_add(&waiter->list_entry, &lock->wait_list);
- current->pi_blocked_on = waiter;
- current->pi_locked_by = NULL;
+ plist_del(&waiter->list_entry, &lock->wait_list);
+ waiter->task = NULL;
+ current->pi_blocked_on = NULL;
spin_unlock(¤t->pi_lock);
- spin_unlock(&lock->wait_lock);
-
- spin_lock(&pi_conflicts_lock);
-
- spin_lock(&lock->wait_lock);
-
- spin_lock(¤t->pi_lock);
- current->pi_locked_by = current;
- /* We might have been woken up: */
- if (!waiter->task) {
- spin_unlock(&pi_conflicts_lock);
- goto out;
- }
+ if (first && owner != current) {
- top_waiter = rt_mutex_top_waiter(lock);
+ spin_lock(&owner->pi_lock);
- plist_del(&waiter->list_entry, &lock->wait_list);
+ plist_del(&waiter->pi_list_entry, &owner->pi_waiters);
- if (waiter != top_waiter || rt_mutex_owner(lock) == current)
- goto out;
+ if (rt_mutex_has_waiters(lock)) {
+ struct rt_mutex_waiter *next;
- /* Get the top priority waiter of the lock: */
- if (rt_mutex_has_waiters(lock))
- next_waiter = rt_mutex_top_waiter(lock);
+ next = rt_mutex_top_waiter(lock);
+ plist_add(&next->pi_list_entry, &owner->pi_waiters);
+ }
+ __rt_mutex_adjust_prio(owner);
- /* Lock the full chain: */
- lock_pi_chain(lock, next_waiter, &lock_chain, 0, 0);
+ if (owner->pi_blocked_on) {
+ boost = 1;
+ get_task_struct(owner);
+ }
+ spin_unlock(&owner->pi_lock);
+ }
- /* Drop the conflicts lock: */
- spin_unlock(&pi_conflicts_lock);
+ WARN_ON(!plist_node_empty(&waiter->pi_list_entry));
- adjust_pi_chain(lock, next_waiter, waiter, &lock_chain);
+ if (!boost)
+ return;
- out_unlock:
- unlock_pi_chain(&lock_chain);
- out:
- current->pi_blocked_on = NULL;
- waiter->task = NULL;
- current->pi_locked_by = NULL;
- spin_unlock(¤t->pi_lock);
+ spin_unlock(&lock->wait_lock);
- WARN_ON(!plist_node_empty(&waiter->pi_list_entry));
+ rt_mutex_adjust_prio_chain(owner, 0, lock, NULL __IP__);
- return 0;
+ spin_lock(&lock->wait_lock);
}
/*
@@ -709,21 +567,18 @@ rt_mutex_slowlock(struct rt_mutex *lock,
{
struct rt_mutex_waiter waiter;
int ret = 0;
- unsigned long flags;
debug_rt_mutex_init_waiter(&waiter);
waiter.task = NULL;
- spin_lock_irqsave(&lock->wait_lock, flags);
+ spin_lock(&lock->wait_lock);
/* Try to acquire the lock again: */
if (try_to_take_rt_mutex(lock __IP__)) {
- spin_unlock_irqrestore(&lock->wait_lock, flags);
+ spin_unlock(&lock->wait_lock);
return 0;
}
- BUG_ON(rt_mutex_owner(lock) == current);
-
set_current_state(state);
/* Setup the timer, when timeout != NULL */
@@ -753,25 +608,30 @@ rt_mutex_slowlock(struct rt_mutex *lock,
/*
* waiter.task is NULL the first time we come here and
* when we have been woken up by the previous owner
- * but the lock got stolen by an higher prio task.
+ * but the lock got stolen by a higher prio task.
*/
if (!waiter.task) {
ret = task_blocks_on_rt_mutex(lock, &waiter,
detect_deadlock __IP__);
- /* got the lock or deadlock: */
- if (ret == 0 || ret == -EDEADLK)
+ /*
+ * If we got woken up by the owner then start loop
+ * all over without going into schedule to try
+ * to get the lock now:
+ */
+ if (unlikely(!waiter.task))
+ continue;
+
+ if (unlikely(ret))
break;
- ret = 0;
}
-
- spin_unlock_irqrestore(&lock->wait_lock, flags);
+ spin_unlock(&lock->wait_lock);
debug_rt_mutex_print_deadlock(&waiter);
if (waiter.task)
schedule_rt_mutex(lock);
- spin_lock_irqsave(&lock->wait_lock, flags);
+ spin_lock(&lock->wait_lock);
set_current_state(state);
}
@@ -786,10 +646,10 @@ rt_mutex_slowlock(struct rt_mutex *lock,
*/
fixup_rt_mutex_waiters(lock);
- spin_unlock_irqrestore(&lock->wait_lock, flags);
+ spin_unlock(&lock->wait_lock);
/* Remove pending timer: */
- if (unlikely(timeout && timeout->task))
+ if (unlikely(timeout))
hrtimer_cancel(&timeout->timer);
/*
@@ -811,10 +671,9 @@ rt_mutex_slowlock(struct rt_mutex *lock,
static inline int
rt_mutex_slowtrylock(struct rt_mutex *lock __IP_DECL__)
{
- unsigned long flags;
int ret = 0;
- spin_lock_irqsave(&lock->wait_lock, flags);
+ spin_lock(&lock->wait_lock);
if (likely(rt_mutex_owner(lock) != current)) {
@@ -826,7 +685,7 @@ rt_mutex_slowtrylock(struct rt_mutex *lo
fixup_rt_mutex_waiters(lock);
}
- spin_unlock_irqrestore(&lock->wait_lock, flags);
+ spin_unlock(&lock->wait_lock);
return ret;
}
@@ -837,9 +696,7 @@ rt_mutex_slowtrylock(struct rt_mutex *lo
static void __sched
rt_mutex_slowunlock(struct rt_mutex *lock)
{
- unsigned long flags;
-
- spin_lock_irqsave(&lock->wait_lock, flags);
+ spin_lock(&lock->wait_lock);
debug_rt_mutex_unlock(lock);
@@ -847,13 +704,13 @@ rt_mutex_slowunlock(struct rt_mutex *loc
if (!rt_mutex_has_waiters(lock)) {
lock->owner = NULL;
- spin_unlock_irqrestore(&lock->wait_lock, flags);
+ spin_unlock(&lock->wait_lock);
return;
}
wakeup_next_waiter(lock);
- spin_unlock_irqrestore(&lock->wait_lock, flags);
+ spin_unlock(&lock->wait_lock);
/* Undo pi boosting if necessary: */
rt_mutex_adjust_prio(current);
@@ -869,8 +726,8 @@ static inline int
rt_mutex_fastlock(struct rt_mutex *lock, int state,
int detect_deadlock,
int (*slowfn)(struct rt_mutex *lock, int state,
- struct hrtimer_sleeper *timeout,
- int detect_deadlock __IP_DECL__))
+ struct hrtimer_sleeper *timeout,
+ int detect_deadlock __IP_DECL__))
{
if (!detect_deadlock && likely(rt_mutex_cmpxchg(lock, NULL, current))) {
rt_mutex_deadlock_account_lock(lock, current);
@@ -883,8 +740,8 @@ static inline int
rt_mutex_timed_fastlock(struct rt_mutex *lock, int state,
struct hrtimer_sleeper *timeout, int detect_deadlock,
int (*slowfn)(struct rt_mutex *lock, int state,
- struct hrtimer_sleeper *timeout,
- int detect_deadlock __IP_DECL__))
+ struct hrtimer_sleeper *timeout,
+ int detect_deadlock __IP_DECL__))
{
if (!detect_deadlock && likely(rt_mutex_cmpxchg(lock, NULL, current))) {
rt_mutex_deadlock_account_lock(lock, current);
@@ -974,7 +831,6 @@ rt_mutex_timed_lock(struct rt_mutex *loc
}
EXPORT_SYMBOL_GPL(rt_mutex_timed_lock);
-
/**
* rt_mutex_trylock - try to lock a rt_mutex
*
@@ -1030,7 +886,7 @@ void __rt_mutex_init(struct rt_mutex *lo
{
lock->owner = NULL;
spin_lock_init(&lock->wait_lock);
- plist_head_init(&lock->wait_list);
+ plist_head_init(&lock->wait_list, &lock->wait_lock);
debug_rt_mutex_init(lock, name);
}
@@ -1050,7 +906,7 @@ void rt_mutex_init_proxy_locked(struct r
struct task_struct *proxy_owner)
{
__rt_mutex_init(lock, NULL);
- debug_rt_mutex_lock(lock __RET_IP__);
+ debug_rt_mutex_proxy_lock(lock, proxy_owner __RET_IP__);
rt_mutex_set_owner(lock, proxy_owner, 0);
rt_mutex_deadlock_account_lock(lock, proxy_owner);
}
Index: linux-pi-futex.mm.q/kernel/rtmutex.h
===================================================================
--- linux-pi-futex.mm.q.orig/kernel/rtmutex.h
+++ linux-pi-futex.mm.q/kernel/rtmutex.h
@@ -19,10 +19,11 @@
#define debug_rt_mutex_init_waiter(w) do { } while (0)
#define debug_rt_mutex_free_waiter(w) do { } while (0)
#define debug_rt_mutex_lock(l) do { } while (0)
+#define debug_rt_mutex_proxy_lock(l,p) do { } while (0)
#define debug_rt_mutex_proxy_unlock(l) do { } while (0)
#define debug_rt_mutex_unlock(l) do { } while (0)
#define debug_rt_mutex_init(m, n) do { } while (0)
#define debug_rt_mutex_deadlock(d, a ,l) do { } while (0)
#define debug_rt_mutex_print_deadlock(w) do { } while (0)
-#define debug_rt_mutex_detect_deadlock(d) (d)
+#define debug_rt_mutex_detect_deadlock(w,d) (d)
#define debug_rt_mutex_reset_waiter(w) do { } while (0)
Index: linux-pi-futex.mm.q/kernel/sched.c
===================================================================
--- linux-pi-futex.mm.q.orig/kernel/sched.c
+++ linux-pi-futex.mm.q/kernel/sched.c
@@ -1522,6 +1522,12 @@ void fastcall sched_fork(task_t *p, int
* event cannot wake it up and insert it on the runqueue either.
*/
p->state = TASK_RUNNING;
+
+ /*
+ * Make sure we do not leak PI boosting priority to the child:
+ */
+ p->prio = current->normal_prio;
+
INIT_LIST_HEAD(&p->run_list);
p->array = NULL;
#ifdef CONFIG_SCHEDSTATS
@@ -3893,7 +3899,6 @@ static void __setscheduler(struct task_s
BUG_ON(p->array);
p->policy = policy;
p->rt_priority = prio;
-
p->normal_prio = normal_prio(p);
/* we are holding p->pi_lock already */
p->prio = rt_mutex_getprio(p);
@@ -3902,7 +3907,6 @@ static void __setscheduler(struct task_s
*/
if (policy == SCHED_BATCH)
p->sleep_avg = 0;
-
set_load_weight(p);
}
Index: linux-pi-futex.mm.q/kernel/sysctl.c
===================================================================
--- linux-pi-futex.mm.q.orig/kernel/sysctl.c
+++ linux-pi-futex.mm.q/kernel/sysctl.c
@@ -132,6 +132,10 @@ extern int acct_parm[];
extern int no_unaligned_warning;
#endif
+#ifdef CONFIG_RT_MUTEXES
+extern int max_lock_depth;
+#endif
+
static int parse_table(int __user *, int, void __user *, size_t __user *, void __user *, size_t,
ctl_table *, void **);
static int proc_doutsstring(ctl_table *table, int write, struct file *filp,
@@ -684,6 +688,17 @@ static ctl_table kern_table[] = {
.proc_handler = &proc_dointvec,
},
#endif
+#ifdef CONFIG_RT_MUTEXES
+ {
+ .ctl_name = KERN_MAX_LOCK_DEPTH,
+ .procname = "max_lock_depth",
+ .data = &max_lock_depth,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec,
+ },
+#endif
+
{ .ctl_name = 0 }
};
Index: linux-pi-futex.mm.q/scripts/rt-tester/t3-l1-pi-signal.tst
===================================================================
--- linux-pi-futex.mm.q.orig/scripts/rt-tester/t3-l1-pi-signal.tst
+++ linux-pi-futex.mm.q/scripts/rt-tester/t3-l1-pi-signal.tst
@@ -69,15 +69,18 @@ W: locked: 0: 0
C: locknowait: 1: 0
W: blocked: 1: 0
T: prioeq: 0: 80
+T: prioeq: 1: 80
# T2 lock L0 interruptible, no wait in the wakeup path
C: lockintnowait: 2: 0
W: blocked: 2: 0
T: prioeq: 0: 81
+T: prioeq: 1: 80
# Interrupt T2
C: signal: 2: 2
W: unlocked: 2: 0
+T: prioeq: 1: 80
T: prioeq: 0: 80
T: locked: 0: 0
^ permalink raw reply
* Re: question on spi_bitbang
From: Kumar Gala @ 2006-03-31 19:17 UTC (permalink / raw)
To: Kumar Gala; +Cc: David Brownell, spi-devel-general, linux kernel mailing list
In-Reply-To: <29F33C89-519A-412B-9615-1944ED29FD9C@kernel.crashing.org>
On Mar 31, 2006, at 1:07 PM, Kumar Gala wrote:
>
> On Mar 31, 2006, at 12:11 PM, David Brownell wrote:
>
>> On Friday 31 March 2006 9:31 am, Kumar Gala wrote:
>>> I'm looking at using spi_bitbang for a SPI driver and was trying to
>>> understand were the right point is to handle MODE switches.
>>>
>>> There are 4 function pointers provided for each mode.
>>
>> That's if you are indeed "bit banging", or your controller is the
>> type that's basically a wrapper around a shift register: each
>> txrx_word() function transfers (or bitbangs) a 1-32 bit word in
>> the relevant SPI mode (0-3).
>>
>> There's also a higher level txrx_bufs() routine for buffer-at-a-time
>> access, better suited to DMA, FIFOs, and half-duplex hardware.
>
> My controller is just a shift register that I can set the
> characteristics of (bit length for example, reverse data).
>
>>> My controller
>>> HW has a mode register which allows setting clock polarity and clock
>>> phase. I assume what I want is in my chipselect() function is to
>>> set
>>> my mode register and have the four function pointers set to the same
>>> function.
>>
>> I don't know how your particular hardware works, but if you have a
>> real SPI controller it would probably be more natural to have your
>> setup() function handle that mode register earlier, out of the main
>> transfer loop ... unless that mode register is shared among all
>> chipselects, in which case you'd use the setup_transfer() call for
>> that, inside the transfer loop. (That call hasn't yet been merged
>> into the mainline kernel yet; it's in the MM tree.)
>
> The mode register is shared between chipselects so I'll go pull the
> patches from -mm for setup_transfer(). That sounds like the right
> place for setting my mode register.
Now that I look at setup_transfer() more I dont think its what I
want. It's only going to get called if the transfer is different
from the spi_device() settings. I would seem I would want to
configure all of my settings in chipselect().
>> The chipselect() call should only affect the chipselect signal and,
>> when you're activating a chip, its initial clock polarity. Though
>> if you're not using the latest from the MM tree, that's also your
>> hook for ensuring that the SPI mode is set up right.
>
> Why deal with just clock polarity and not clock phase as well in
> chipselect()?
>
> It sounds like with the new patch, I'll end up setting txrx_word[]
> to the same function for all modes.
>
> - kumar
> -
> To unsubscribe from this list: send the line "unsubscribe linux-
> kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* [ALSA - driver 0001987]: Upmix Feature Request
From: bugtrack @ 2006-03-31 19:15 UTC (permalink / raw)
To: alsa-devel
The following issue has been REOPENED.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1987>
======================================================================
Reported By: the-me
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 1987
Category: CORE - control
Reproducibility: always
Severity: feature
Priority: normal
Status: feedback
Distribution: Debian
Kernel Version: 2.6.16.1
======================================================================
Date Submitted: 03-31-2006 20:38 CEST
Last Modified: 03-31-2006 21:15 CEST
======================================================================
Summary: Upmix Feature Request
Description:
Hi,
I, and many users more, want a feature at the alsamixer, called Upmix.
I've got an Terratec Aureon 5.1 Fun and I tried many things, but it's not
able, that I can hear an mp3 with upmixed 5.1 sound. Here is my actual
.asoundrc:
pcm.ch51upmix {
type route
slave.pcm surround51
slave.channels 6
ttable.0.0 1
ttable.1.1 1
ttable.0.2 1
ttable.1.3 1
ttable.0.4 0.5
ttable.1.4 0.5
ttable.0.5 0.5
ttable.1.5 0.5
}
pcm.!default
{
type plug
slave.pcm ch51upmix
}
pcm.lowpass {
type ladspa
path "/usr/lib/ladspa"
plugins [ {
label lpf
input {
controls [ 50 ]
}
} ]
}
With this .asoundrc, all speakers work, but my subwoofer doesn't play only
low frequen...
Can you please add such a feature?
Greetz, Patrick
======================================================================
----------------------------------------------------------------------
rlrevell - 03-31-06 21:02
----------------------------------------------------------------------
Feature requests should be posted to the alsa-user list rather than the bug
tracker. There's already a thread "How to use Surroundsound with alsa??"
that you can add your comments to.
----------------------------------------------------------------------
the-me - 03-31-06 21:15
----------------------------------------------------------------------
But I need upmixing, no real Surroundsound.
And I dont know, how to use this lists :/
Issue History
Date Modified Username Field Change
======================================================================
03-31-06 20:38 the-me New Issue
03-31-06 20:38 the-me Distribution => Debian
03-31-06 20:38 the-me Kernel Version => 2.6.16.1
03-31-06 20:40 the-me Note Added: 0009048
03-31-06 21:02 rlrevell Status new => closed
03-31-06 21:02 rlrevell Note Added: 0009049
03-31-06 21:15 the-me Status closed => feedback
03-31-06 21:15 the-me Resolution open => reopened
03-31-06 21:15 the-me Note Added: 0009050
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: The sort algorithm is broken by the second rule, We need a way to pin these rules to the top.
From: Stephen Smalley @ 2006-03-31 19:15 UTC (permalink / raw)
To: Ivan Gyurdiev
Cc: Joshua Brindle, Christopher J. PeBenito, Daniel J Walsh, SE Linux
In-Reply-To: <442D7CFC.8060704@cornell.edu>
On Fri, 2006-03-31 at 14:03 -0500, Ivan Gyurdiev wrote:
> > Sorting is presently only
> > happening in the policy build process via the
> > refpolicy/support/fc_sort.c helper program, so it is only applied to the
> > file_context file provided by the policy itself, not to any local
> > entries (whether created via semanage or not).
> >
> My mistake, I thought sorting was moved into matchpathcon at some point...
> In that case the patch I sent shouldn't be necessary.
Yes, Joshua had sent a patch to add the sorting logic to matchpathcon
back in Oct '05, but I rejected it at the time because it needed to be
coordinated with a policy update to ensure no actual change in
filesystem labeling and because it sorted all of the file_contexts.*
files together rather than retaining a prioritization among them. And
as we later agreed, it belongs in libsemanage at generation time rather
than in libselinux.
Current libselinux matchpathcon logic only moves exact specifications
(no regex in the pathname) to the end so that they are never overridden
by a pathname regex; otherwise, it just uses the provided ordering
within each file and it uses a fixed ordering among the files
(file_contexts.local takes precedence over file_contexts.homedirs which
takes precedence over file_contexts).
What is a little confusing right now is that there are potentially two
"file_contexts.local" files; the one managed via semanage that only
exists in the store and is merged to the end of the generated
file_contexts file for installation and the one that can be manually
created by the admin that is "merged" to the end of the in-memory table
by matchpathcon. I suppose we should consider the latter to be
deprecated but libselinux will continue to look for it for legacy
support.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.