From: John David Anglin <dave.anglin@bell.net>
To: Mikulas Patocka <mpatocka@redhat.com>, Helge Deller <deller@gmx.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-parisc@vger.kernel.org,
James Bottomley <James.Bottomley@HansenPartnership.com>
Subject: Re: [GIT PULL] parisc huge page support for v4.4
Date: Mon, 4 Jan 2016 16:48:11 -0500 [thread overview]
Message-ID: <568AE89B.9030606@bell.net> (raw)
In-Reply-To: <alpine.LRH.2.02.1601041619070.20474@file01.intranet.prod.int.rdu2.redhat.com>
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@bell.net
prev parent reply other threads:[~2016-01-04 22:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-22 11:51 [GIT PULL] parisc huge page support for v4.4 Helge Deller
2015-11-24 15:51 ` Mikulas Patocka
2015-11-24 15:58 ` Helge Deller
2015-11-24 16:39 ` Mikulas Patocka
2015-11-24 17:00 ` Helge Deller
2015-11-24 18:43 ` Mikulas Patocka
2015-12-26 12:09 ` Mikulas Patocka
2015-12-26 12:31 ` Helge Deller
2016-01-04 21:24 ` Mikulas Patocka
2016-01-04 21:48 ` John David Anglin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=568AE89B.9030606@bell.net \
--to=dave.anglin@bell.net \
--cc=James.Bottomley@HansenPartnership.com \
--cc=deller@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).