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] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LRH.2.02.1601041619070.20474@file01.intranet.prod.int.rdu2.redhat.com>
Date:	Mon, 4 Jan 2016 16:24:57 -0500 (EST)
From:	Mikulas Patocka <mpatocka@...hat.com>
To:	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>,
	John David Anglin <dave.anglin@...l.net>
Subject: Re: [GIT PULL] parisc huge page support for v4.4



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?

Mikulas
--
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/