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

From: Oliver Neukum []
Sent: Friday, March 21, 2014 8:35 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:
> >How is that different from any other time a task has to yield the CPU
> >for a bit?  While your high priority task is blocked for whatever
> >reason, a lower priority task gets to use the CPU.
> 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.
> mlock() doesn't block.  check the man page.

It guarantees that all pages be in RAM. That means it has to read them
in if they aren't. How could it do that without blocking?


I would assume it would touch some flag bits on every page.  As part of the thread of execution that called it.

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.

For many years it returned when finished.  Now, it blocks.

This makes code that used to work, not work.  

I consider it a defect.

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