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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170921061631.2afa4e40@lwn.net>
Date:   Thu, 21 Sep 2017 06:16:31 -0600
From:   Jonathan Corbet <corbet@....net>
To:     "XaviLi" <ljy@...bantech.com.cn>
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 16:25:39 +0800
"XaviLi" <ljy@...bantech.com.cn> wrote:

> We raised a topic about PPR (Per Page Recycler) and thank to Jan Kiszka
> for advises. We are here to break up patch codes and explain the code
> in detail. There are too many things to explain in one topic. We would
> like to do it part by part. Content of original mails and patches can
> be found below in the end.

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.

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.

jon