[<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