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:50:34 +0000
From:	<>
To:	<>
CC:	<>, <>,
	<>, <>,
Subject: RE: Bug 71331 - mlock yields processor to lower priority process

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

On Fri, 2014-03-21 at 14:01 +0000, wrote:

> If you call mlock () from a SCHED_FIFO task, you expect it to return
> when done.  You don't expect it to block, and your task to be
> pre-empted.

Say some of your pages are sitting in an nfs swapfile orbiting Neptune,
how do they get home, and what should we do meanwhile?


Two options.

#1. Return with a status value of EAGAIN.


#2.  Don't return until you can do it.

If SCHED_FIFO is used, and mlock() is called, the intention of the user is very clear.  Run this task until
it is completed or it blocks (and until a bit ago, mlock() did not block).

SCHED_FIFO users don't care about fairness.  They want the system to do what it is told.

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