[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7a4fcbaee7efb71d2a3c6b403c090db4@codeaurora.org>
Date: Wed, 24 Oct 2018 10:47:52 +0530
From: Arun KS <arunks@...eaurora.org>
To: Kees Cook <keescook@...omium.org>
Cc: Konstantin Khlebnikov <khlebnikov@...dex-team.ru>,
Joe Perches <joe@...ches.com>,
LKML <linux-kernel@...r.kernel.org>,
linux-mm <linux-mm@...ck.org>, Minchan Kim <minchan@...nel.org>,
Michal Hocko <mhocko@...e.com>,
Arun Sudhilal <getarunks@...il.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] mm: convert totalram_pages, totalhigh_pages and
managed_pages to atomic.
On 2018-10-24 01:34, Kees Cook wrote:
> On Mon, Oct 22, 2018 at 10:11 PM, Konstantin Khlebnikov
> <khlebnikov@...dex-team.ru> wrote:
>> On 23.10.2018 7:15, Joe Perches wrote:> On Mon, 2018-10-22 at 22:53
>> +0530,
>> Arun KS wrote:
>>>> Remove managed_page_count_lock spinlock and instead use atomic
>>>> variables.
>>>
>>> Perhaps better to define and use macros for the accesses
>>> instead of specific uses of atomic_long_<inc/dec/read>
>>>
>>> Something like:
>>>
>>> #define totalram_pages() (unsigned
>>> long)atomic_long_read(&_totalram_pages)
>>
>> or proper static inline
>> this code isn't so low level for breaking include dependencies with
>> macro
>
> BTW, I noticed a few places in the patch that did multiple evaluations
> of totalram_pages. It might be worth fixing those prior to doing the
> conversion, too. e.g.:
>
> if (totalram_pages > something)
> foobar(totalram_pages); <- value may have changed here
>
> should, instead, be:
>
> var = totalram_pages; <- get stable view of the value
> if (var > something)
> foobar(var);
Thanks for reviewing. Point taken.
>
> -Kees
>
>> [dropped bloated cc - my server rejects this mess]
>
> Thank you -- I was struggling to figure out the best way to reply to
> this. :)
I'm sorry for the trouble caused. Sent the email using,
git send-email --to-cmd="scripts/get_maintainer.pl -i"
0001-convert-totalram_pages-totalhigh_pages-and-managed_p.patch
Is this not a recommended approach?
Regards,
Arun
>
> -Kees
Powered by blists - more mailing lists