search for: mlocks

From: Martin Schwidefsky <schwidefsky@de.ibm.com> From: Hubertus Franke <frankeh@watson.ibm.com> From: Himanshu Raj <rhim@cc.gatech.edu> [patch 5/9] Guest page hinting: mlocked pages. Add code to get mlock() working with guest page hinting. The problem with mlock is that locked pages may not be removed from page cache. That means they need to be stable. page_make_volatile needs

From: Martin Schwidefsky <schwidefsky@de.ibm.com> From: Hubertus Franke <frankeh@watson.ibm.com> From: Himanshu Raj <rhim@cc.gatech.edu> [patch 5/9] Guest page hinting: mlocked pages. Add code to get mlock() working with guest page hinting. The problem with mlock is that locked pages may not be removed from page cache. That means they need to be stable. page_make_volatile needs

c:\APPS\TINC\tincd.exe --mlock --net=mynet --config=C:\APPS\tinc\mynet Without --mlock, the service starts OK. With --mlock, the service fails to start.

There's one vulnerability that's bugged me for some time. It applies to nearly all crypto software, including ssh. That's the swapping of sensitive info (such as keys and key equivalents) onto hard drives where they could possibly be recovered later. The Linux kernel provides a system call, mlock(), that inhibits swapping of a specified region of virtual memory. It locks it into real

Last year we had a discussion[1] about how the hypercall ABI unfortunately contains fields that change width between 32- and 64-bit builds. This is a huge problem as we come up on the python management stack for ppc64, since the distributions ship 32-bit python. A 32-bit python/libxc cannot currently manage a 64-bit hypervisor. I had a patch but was unable to test it, and some other things were

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is there any interest in using mlock to lock pages in core so that potentially sensitive data won't get swapped out to disk? (GnuPG, for example, does this). There was a thread on this a long time ago, and it degenerated into a discussion of crypto-swap, but the question was never answered. Is there a good reason not to do this? The only one

So as best practice running tinc I should include it ? Regards Yazeed Fataar <yazeedfataar at hotmail.com> On Sun, Feb 14, 2016 at 1:08 PM, Guus Sliepen <guus at tinc-vpn.org> wrote: > On Sun, Feb 14, 2016 at 10:53:19AM +0300, Yazeed Fataar wrote: > > > Going through the options tinc has . Can someone explain exactly what the > > purpose is for -L option for the

Hi All Going through the options tinc has . Can someone explain exactly what the purpose is for -L option for the runtime command. So does this mean that tinc will run in RAM and will not be saved in swap (default) ? ================ -L, --mlock Lock tinc into main memory. This will prevent sensitive data like shared private keys to be written to the system swap

On Sun, Feb 14, 2016 at 01:12:11PM +0300, Yazeed Fataar wrote: > So as best practice running tinc I should include it ? I personally see little value in it. If you want to enable it, be sure to understand the implications of locking a process in RAM; you should have more RAM than the tincd process memory will ever use, and you should check that there are no resource limits that prevent tinc

On Wed, 2014-01-08 at 21:18 +0200, Michael S. Tsirkin wrote: > On Wed, Jan 08, 2014 at 10:26:03AM -0800, Eric Dumazet wrote: > > On Wed, 2014-01-08 at 20:08 +0200, Michael S. Tsirkin wrote: > > > > > Eric said we also need a patch to add __GFP_NORETRY, right? > > > Probably before this one in series. > > > > Nope, this __GFP_NORETRY has nothing to do

On Wed, 2014-01-08 at 21:18 +0200, Michael S. Tsirkin wrote: > On Wed, Jan 08, 2014 at 10:26:03AM -0800, Eric Dumazet wrote: > > On Wed, 2014-01-08 at 20:08 +0200, Michael S. Tsirkin wrote: > > > > > Eric said we also need a patch to add __GFP_NORETRY, right? > > > Probably before this one in series. > > > > Nope, this __GFP_NORETRY has nothing to do

On Sun, Feb 14, 2016 at 10:53:19AM +0300, Yazeed Fataar wrote: > Going through the options tinc has . Can someone explain exactly what the > purpose is for -L option for the runtime command. > > So does this mean that tinc will run in RAM and will not be saved in swap > (default) ? Yes, that's exactly what it does. -- Met vriendelijke groet / with kind regards, Guus

Hi, secpwgen is always reporting "mlock: Cannot allocate memory" even with user root. CentOS 6.2. Problem with selinux? Thank you for help in advance. Best regards Helmut Drodofsky

On Mon, 2004-10-18 at 22:14, Paul Davis wrote: > jackd (realtime) requires various resources which it shares with its > clients: > > realtime scheduling > mlock-ability > shared memory segments > FIFOs (or Mach ports on OS X) > > we consider it *more* of a security risk to allow jackd-as-root to > share these with non-root processes. YMMV.

>I can't really comment on jackd itself, as I haven't looked that much >into it. If running jackd as root requires client apps to also run as >root then that is a pretty bad issue. I would of thought that running >jackd as a realtime process (whether root or not) would be an important >consideration. jackd (realtime) requires various resources which it shares with its

Hi all, Recently I build XEN 4.1 (from the xen.org) on centIOS 5.5 (kernel 2.6.38.4). After changing the grub file and rebooting the machine, I am continuously getting out of memory error. The content of my grub file: default=0 timeout=5 serial --unit=0 --speed=115200 terminal --timeout=10 console serial splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title CentOS (2.6.38.4) root

https://bugs.freedesktop.org/show_bug.cgi?id=93458 Bug ID: 93458 Summary: page allocation failure: order:5, mode:0x240c0c0 Product: xorg Version: 7.7 (2012.06) Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau

On 09/01/2017 02:41 PM, Kevin Stange wrote: > On 08/31/2017 07:50 AM, PJ Welsh wrote: >> A recently created and fully functional CentOS 7.3 VM fails to boot >> after applying CR updates: > <snip> >> Server OS is CentOS 7.3 using Xen (no CR updates): >> rpm -qa xen\* >> xen-hypervisor-4.6.3-15.el7.x86_64 >> xen-4.6.3-15.el7.x86_64 >>

...You may want to consider GFP_NOKSWAPD, because even in the GFP_ATOMIC case you are waking up kswapd to do reclaims on a continuous basis even when you don't enter direct reclaim. 3. mlocking memory had very little to do with it, that was a red-herring. I tested out the problem scenario with no mlocks. You simply need memory pressure from page_cache, and mm ends up constantly reclaiming and trying to keep another 1-2GB free on our systems (8GB phys ~4GB left for kernel, ~3GB optimally used for page_cache). 4. I think perhaps using a kmem_cache allocation for this buffer is the right way to make...

Hello, I''m running into some trouble with what appear on the surface to be OOM issues in Dom0, but I''m not seeing any other evidence. This typically happens during periods of high I/O, and has occurred during RAID initial sync, and mkfs.ext4ing (as a test, no intention to keep ext4 on this array). I''ve found some older posts citing very similar circumstances, however