2015-07-22 13:29:33

by Pan Xinhui

[permalink] [raw]
Subject: [PATCH V4] x86/mm/pat: Do a small optimization and fix in reserve_memtype

From: Pan Xinhui <[email protected]>

It's more reasonable to unlock memtype_lock right after
rbt_memtype_check_insert. All pat_rbtree operations need to be performed
while holding the memtype_lock. But codes like kfree, pr_info, etc have
nothing to do with this lock. So move spin_unlock a little ahead.

If *new* succeed to be stored into the rb-tree, we might hit panic.
Because we access *new* in dprintk "cattr_name(new->type)". Data stored
in the rb-tree might be freed at any possible time. It's obviously wrong
to access such data without lock held.

We use actual_type instead of new->type in dprintk. Two benefits, 1) We
don't touch *new* here now so panic can be avoided. 2) As new->type is
same with *new_type, We needn't to print it again, what's more, this
actual_type's output can help debug. When new_type is NULL, actual_type
is equal to new->type, So no key information is lost.

Do a minor codes style improvement.

Signed-off-by: Pan Xinhui <[email protected]>
---
change from v3:
output actual_type instead of new->type.
codes style improvement.
update comments.
change from v2:
update comments.
change from V1:
fix an access of *new* without memtype_lock held.
---
arch/x86/mm/pat.c | 14 ++++----------
1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 188e3e0..8fa1f07 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -521,10 +521,7 @@ int reserve_memtype(u64 start, u64 end, enum page_cache_mode req_type,

is_range_ram = pat_pagerange_is_ram(start, end);
if (is_range_ram == 1) {
-
- err = reserve_ram_pages_type(start, end, req_type, new_type);
-
- return err;
+ return reserve_ram_pages_type(start, end, req_type, new_type);
} else if (is_range_ram < 0) {
return -EINVAL;
}
@@ -538,22 +535,19 @@ int reserve_memtype(u64 start, u64 end, enum page_cache_mode req_type,
new->type = actual_type;

spin_lock(&memtype_lock);
-
err = rbt_memtype_check_insert(new, new_type);
+ spin_unlock(&memtype_lock);
+
if (err) {
pr_info("x86/PAT: reserve_memtype failed [mem %#010Lx-%#010Lx], track %s, req %s\n",
start, end - 1,
cattr_name(new->type), cattr_name(req_type));
kfree(new);
- spin_unlock(&memtype_lock);
-
return err;
}

- spin_unlock(&memtype_lock);
-
dprintk("reserve_memtype added [mem %#010Lx-%#010Lx], track %s, req %s, ret %s\n",
- start, end - 1, cattr_name(new->type), cattr_name(req_type),
+ start, end - 1, cattr_name(actual_type), cattr_name(req_type),
new_type ? cattr_name(*new_type) : "-");

return err;
--
1.9.1


Subject: RE: [PATCH V4] x86/mm/pat: Do a small optimization and fix in reserve_memtype



---
Robert Elliott, HP Server Storage

> -----Original Message-----
> From: [email protected] [mailto:linux-kernel-
> [email protected]] On Behalf Of Pan Xinhui
> Sent: Wednesday, July 22, 2015 8:27 AM
...
> diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
> index 188e3e0..8fa1f07 100644
> --- a/arch/x86/mm/pat.c
> +++ b/arch/x86/mm/pat.c
> @@ -521,10 +521,7 @@ int reserve_memtype(u64 start, u64 end, enum
> page_cache_mode req_type,
>
> is_range_ram = pat_pagerange_is_ram(start, end);
> if (is_range_ram == 1) {
> -
> - err = reserve_ram_pages_type(start, end, req_type, new_type);
> -
> - return err;
> + return reserve_ram_pages_type(start, end, req_type, new_type);
> } else if (is_range_ram < 0) {
> return -EINVAL;
> }

With each branch now just one line, the {} can be removed.



????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?

2015-07-22 14:45:59

by Borislav Petkov

[permalink] [raw]
Subject: Re: [PATCH V4] x86/mm/pat: Do a small optimization and fix in reserve_memtype

On Wed, Jul 22, 2015 at 02:38:28PM +0000, Elliott, Robert (Server Storage) wrote:
> With each branch now just one line, the {} can be removed.

... and I had suggested it without the {}.

--
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

2015-07-23 01:58:13

by Pan Xinhui

[permalink] [raw]
Subject: Re: [PATCH V4] x86/mm/pat: Do a small optimization and fix in reserve_memtype


hi, Elliot
thanks for your reply.
On 2015年07月22日 22:38, Elliott, Robert (Server Storage) wrote:
>
>
> ---
> Robert Elliott, HP Server Storage
>
>> -----Original Message-----
>> From: [email protected] [mailto:linux-kernel-
>> [email protected]] On Behalf Of Pan Xinhui
>> Sent: Wednesday, July 22, 2015 8:27 AM
> ...
>> diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
>> index 188e3e0..8fa1f07 100644
>> --- a/arch/x86/mm/pat.c
>> +++ b/arch/x86/mm/pat.c
>> @@ -521,10 +521,7 @@ int reserve_memtype(u64 start, u64 end, enum
>> page_cache_mode req_type,
>>
>> is_range_ram = pat_pagerange_is_ram(start, end);
>> if (is_range_ram == 1) {
>> -
>> - err = reserve_ram_pages_type(start, end, req_type, new_type);
>> -
>> - return err;
>> + return reserve_ram_pages_type(start, end, req_type, new_type);
>> } else if (is_range_ram < 0) {
>> return -EINVAL;
>> }
>
> With each branch now just one line, the {} can be removed.
>
thanks for the nice tips. sorry for my mistakes.

thanks
xinhui
>
>

2015-07-23 02:02:40

by Pan Xinhui

[permalink] [raw]
Subject: Re: [PATCH V4] x86/mm/pat: Do a small optimization and fix in reserve_memtype

hi, Borislav
very kind of you. :)
On 2015年07月22日 22:45, Borislav Petkov wrote:
> On Wed, Jul 22, 2015 at 02:38:28PM +0000, Elliott, Robert (Server Storage) wrote:
>> With each branch now just one line, the {} can be removed.
>
> ... and I had suggested it without the {}.
>
hmm, sorry for my mistakes.
Now I have to send patch V5 to you, the version number 5 is a little big for a simple patch like this..

thanks
xinhui