linux-kernel - Re: [PATCH] mm: memcontrol: Use int for event/state parameter in several functions

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]

Date:   Fri, 28 Jul 2017 15:52:36 -0400
From:   Johannes Weiner <hannes@...xchg.org>
To:     Matthias Kaehlcke <mka@...omium.org>
Cc:     Michal Hocko <mhocko@...nel.org>,
        Vladimir Davydov <vdavydov.dev@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-kernel@...r.kernel.org, cgroups@...r.kernel.org,
        linux-mm@...ck.org, Doug Anderson <dianders@...omium.org>
Subject: Re: [PATCH] mm: memcontrol: Use int for event/state parameter in
 several functions

On Fri, Jul 28, 2017 at 11:23:54AM -0700, Matthias Kaehlcke wrote:
> El Thu, Jul 27, 2017 at 02:10:04PM -0700 Matthias Kaehlcke ha dit:
> 
> > Several functions use an enum type as parameter for an event/state,
> > but are called in some locations with an argument of a different enum
> > type. Adjust the interface of these functions to reality by changing the
> > parameter to int.
> > 
> > This fixes a ton of enum-conversion warnings that are generated when
> > building the kernel with clang.

Thanks for fixing this, Matthias.

Acked-by: Johannes Weiner <hannes@...xchg.org>

> While building for another target with a different configuration I
> noticed that inc/dec/mod_memcg_page_state() are also called with a
> conflicting enum type. Changing the parameter type for these functions
> also would make the API more consistent, with the current patch there
> is a somewhat odd mix of related functions, with some receiving an
> enum and others an int.
> 
> Depending on your preference I can send a v3 of this patch or a
> separate patch to address the remaining functions (since this patch
> has already been added to -mm).

Since it's the exact same rationale for the other functions, it would
make sense to me to do a v3 that includes the remaining sites.