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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 21 Mar 2014 14:34:19 +0000
From:	<>
To:	<>
CC:	<>, <>,
	<>, <>
Subject: RE: Bug 71331 - mlock yields processor to lower priority process

From: Mike Galbraith []
Sent: Friday, March 21, 2014 8:14 AM
To: Davis, Bud @ SSG - Link
Subject: RE: Bug 71331 - mlock yields processor to lower priority process

On Fri, 2014-03-21 at 12:18 +0000, wrote:

> As the submitter of the bug, let me give you my perspective.
> SCHED_FIFO means run my task until it blocks or a higher priority task
> pre-empts it.  Period.

It blocked.
> mlock() doesn't block. check the man page.
I don't see that specified.

(or how it could be, but what do I know, IANIPL)

> Any other way and you are not able to use priority based scheduling.

Sure you can, allocate and lock down resources before entering critical

If you think donning a SCHED_FIFO super-suit should make your task
unstoppable, you're gonna be very disappointed.  Fact is if your
Juggernaut bumps ever so gently into a contended sleeping variety lock
(and in the rt kernel that means nearly every lock), it will block.



There are several problem domains where you protect critical sections by assigning multiple
threads to a single CPU and use priorities and SCHED_FIFO to ensure data integrity.

In this kind of design you don't make many syscalls.  The ones you do make, have to be clearly understood
if they block.   

So, yes, I expect that a SCHED_FIFO task, that uses a subset of syscalls known to be non-blocking, will not block.  

If it is not 'unstoppable', then there is a defect in the OS.

In the past, a call to mlock() was known to be OK.  It would not block.  It might take a while, but it would run to completion.  It does not do that any more.

If mlock() is now a blocking call, then fine.  It only needs to be called on occasion, and this can be accounted for
in the application design.  Does write() block ?  Yes, the man pages talks all about it.  Does clock_gettime() block ?
No, blocking is not mentioned in the man page.  Blocking behaviour is rare, when it exists it is documented.

My point is, this is either a defect to be fixed, or a change that warrants updating the documentation.

Bud Davis




To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists