DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:content-type:content-transfer-encoding;
        b=tfdRwvQZC1ORzgZgUsRx2cdtt1ayaCHZi79IrwjMWQ4ufrsvy+vZWFZl+u9LJpc20v90CapW2ac++eEB/29cZSNBis/vl7njbtX/Ru2j8SHMRB95V1WNZBPqb03hLoxt6W2G1l9clesRHYTGmoOB6J7m4o+Ps3YX0Ar3rwEnnpA=
Message-ID: <4642CB06.2080409@gmail.com>
Date: Thu, 10 May 2007 15:34:30 +0800
From: Li Yu <raise.sail@gmail.com>
User-Agent: Thunderbird 1.5.0.10 (X11/20070403)
MIME-Version: 1.0
To: Steven Rostedt <srostedt@redhat.com>
CC: LKML <linux-kernel@vger.kernel.org>
Subject: Hi, I have one question about rt_mutex.
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1144
Lines: 32

Hi, Steven.

Nice to meet you again.

I have read the rt-mutex-design.txt that you wrote. That is excellent
description of rt_mutex. But I have a question for rt_mutex.

As you said:


> Now since mutexes can be defined by user-land applications, we don't
want a DOS
> type of application that nests large amounts of mutexes to create a large
> PI chain, and have the code holding spin locks while looking at a large
> amount of data. So to prevent this, the implementation not only implements
> a maximum lock depth, but also only holds at most two different locks at a
> time, as it walks the PI chain. More about this below.

After read the implementation of rt_mutex_adjust_prio_chain(), I found
the we really require maximin lock depth (1024 default), but I can not
see the check for more same locks duplication. Does this doc is
inconsistent with code?

Thanks in advanced.

Good luck.
- Li Yu
-
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/