linux-kernel - Re: [RFC] [Resend] Another Para-Virtualization page recycler -- Code details, Trap-less way to return free pages to kernel

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: <6690952a-4ba8-406e-80a2-d839fd19e7fa.ljy@baibantech.com.cn>
Date:   Fri, 22 Sep 2017 16:33:05 +0800
From:   "XaviLi" <ljy@...bantech.com.cn>
To:     "Jonathan Corbet" <corbet@....net>
Cc:     "kvm" <kvm@...r.kernel.org>,
        "linux-kernel" <linux-kernel@...r.kernel.org>,
        "Jan Kiszka" <jan.kiszka@...mens.com>,
        "杨泽昕" <yzx@...bantech.com.cn>,
        "王斌" <wb@...bantech.com.cn>,
        "李珅" <lishen@...bantech.com.cn>
Subject: Re: [RFC] [Resend] Another Para-Virtualization page recycler -- Code details, Trap-less way to return free pages to kernel

On Thu ,21 Sep 2017 20:16 +0800
Jonathan Corbet <corbet@....net> wrote:
> If you want these patches to be reviewed, you really need to submit a
> proper patch series.  Please look at
> Documentation/process/submitting-patches.rst for all the details.

> You will also want to make the code compliant with the kernel's coding
> style.

Thank you for your advice. We have switched to the upstream Linux version and updated the project code. 
Now we are working on code compliant. The patch will be refreshed once finished.

> I have not reviewed this code (nor am I really the person to do a proper
> review), but this jumped at me:

>>                         while(mark->desc != 0)
>>                         {
>>                             barrier();
>>                         }

> Busy waits in the memory-management code are going to raise a lot of
> eyebrows, and you really need to document what you think that barrier()
> call is doing.  I suspect it's not giving you the protection you think it
> is.

Your advice is very valuable for this piece of code.

This is a special case of lock-less operation. The PIP pointer acts like a ticket. Once set, only one host or guest thread can get it (protected by CAS). 
The APP see the indicator exist and failed to fetch the pointer, in normal case, it means kernel is recycling the same page. 
This APP side code is spinning on the indicator to wait for the host to finish the recycling. 
The barrier() call is refreshing cache to see the result in time. We choose the spinning way because other waiting methods are heavier than the host operation we are waiting for (about 4000 cycles worst case). 

Your pointing out let us notice that:
It is a possibility that the while() never quit. This is probably rises by two cases as far as we can imagine.
1． Host Kernel is experiencing a serious malfunctioning.
2． APP or Guest OS memory pool corrupts so that two allocators get the same page.

Both cases we have not found a way to survive or finish the job. But that is not a proper reason to leave it unhandled. We should also keep in mind to document the codes that can rise questions.

Thanks again for your precious time and suggestions！

ljy@...bantech.com.cn