linux-kernel - Re: [GIT PULL] parisc huge page support for v4.4

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]

Message-ID: <568AE89B.9030606@bell.net>
Date:	Mon, 4 Jan 2016 16:48:11 -0500
From:	John David Anglin <dave.anglin@...l.net>
To:	Mikulas Patocka <mpatocka@...hat.com>, Helge Deller <deller@....de>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-parisc@...r.kernel.org,
	James Bottomley <James.Bottomley@...senPartnership.com>
Subject: Re: [GIT PULL] parisc huge page support for v4.4

On 2016-01-04 4:24 PM, Mikulas Patocka wrote:
>
> On Sat, 26 Dec 2015, Helge Deller wrote:
>
>> On 26.12.2015 13:09, Mikulas Patocka wrote:
>>
>>> BTW. I looked at this in arch/parisc/mm/hugetlbpage.c:set_huge_pte_at
>>> "*ptep = entry;" and it seems like a bad bug. PA-RISC doesn't have atomic
>>> instructions to modify page table entries, so it takes spinlock in the TLB
>>> handler and modifies the page table entry non-atomically. If you modify
>>> the page table entry without the spinlock, you may race with TLB handler
>>> on another CPU and your modification may be lost.
>> Right.
>>
>>> The comment says something about double locking on pa_tlb_lock, but
>>> pa_tlb_lock isn't held when that function is called.
>> I have a work-in-progress patch for that in one of my trees, e.g.:
>> http://git.kernel.org/cgit/linux/kernel/git/deller/parisc-linux.git/commit/?h=parisc-next&id=5c76b525cbdb097401f46522b27b1eb6244f34f9
>> It's lightly tested though.
>>
>> Helge
> I tested the patch and it works OK for me so far.
>
> BTW. what happens if some kernel code takes the TLB spinlock and then TLB
> miss in kernel space happens? (it would attempt to lock the spinlock
> recursively) Is it assumed that the TLB is big enough that this can't
> happen?
No.  If you look at the TLB handler, you will see that locking is not 
done for misses in
kernel space.  So, this deadlock doesn't occur.

Dave

-- 
John David Anglin  dave.anglin@...l.net

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/