linux-kernel - Re: Hi, I have one question about rt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0705100947570.12299@frodo.shire>
Date:	Thu, 10 May 2007 10:19:00 +0200 (CEST)
From:	Esben Nielsen <nielsen.esben@...glemail.com>
To:	Li Yu <raise.sail@...il.com>
cc:	Steven Rostedt <srostedt@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Hi, I have one question about rt_mutex.



On Thu, 10 May 2007, Li Yu wrote:

> 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

At the label "again:" inside rt_mutex_adjust_prio_chain() no spinlocks are 
held. That is the kernel can reschedule at that point in the loop. So if 
you as a priority X task try to take a lock you will not delay any higher 
priority than X by more than the amount of time it takes to go 
around in the loop once. The max lock depth is just an extra safety.

The whole idea in a priority based real-time system is that the latency on 
priorty X only depends on what is going on at priority X and higher 
(including interrupt handlers). What ever goes on at lower priority can only
interfere with a fixed, predetermined, small amount of jitter.

Esben

> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/