[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <878tabvjw1.fsf@morokweng.localdomain>
Date:   Wed, 28 Mar 2018 20:51:42 -0300
From:   Thiago Jung Bauermann <bauerman@...ux.vnet.ibm.com>
To:     Dave Hansen <dave.hansen@...el.com>
Cc:     Ram Pai <linuxram@...ibm.com>, shuahkh@....samsung.com,
        linux-kselftest@...r.kernel.org, mpe@...erman.id.au,
        linuxppc-dev@...ts.ozlabs.org, linux-mm@...ck.org, x86@...nel.org,
        linux-arch@...r.kernel.org, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, mingo@...hat.com,
        akpm@...ux-foundation.org, benh@...nel.crashing.org,
        paulus@...ba.org, khandual@...ux.vnet.ibm.com,
        aneesh.kumar@...ux.vnet.ibm.com, bsingharora@...il.com,
        hbabu@...ibm.com, mhocko@...nel.org, ebiederm@...ssion.com,
        arnd@...db.de
Subject: Re: [PATCH v12 07/22] selftests/vm: fixed bugs in pkey_disable_clear()
Dave Hansen <dave.hansen@...el.com> writes:
> On 03/28/2018 01:47 PM, Thiago Jung Bauermann wrote:
>>>>  	if (flags)
>>>> -		assert(rdpkey_reg() > orig_pkey_reg);
>>>> +		assert(rdpkey_reg() < orig_pkey_reg);
>>>>  }
>>>>
>>>>  void pkey_write_allow(int pkey)
>>> This seems so horribly wrong that I wonder how it worked in the first
>>> place.  Any idea?
>> The code simply wasn't used. pkey_disable_clear() is called by
>> pkey_write_allow() and pkey_access_allow(), but before this patch series
>> nothing called either of these functions.
>> 
>
> Ahh, that explains it.  Can that get stuck in the changelog, please?
Yes, will be in the next version.
-- 
Thiago Jung Bauermann
IBM Linux Technology Center
Powered by blists - more mailing lists