[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <34fd1ae9-9697-ac6c-d6bc-7c25b4515a25@intel.com>
Date: Wed, 28 Mar 2018 13:55:33 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Thiago Jung Bauermann <bauerman@...ux.vnet.ibm.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()
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?
Powered by blists - more mailing lists