From: John David Anglin <dave.anglin@bell.net>
To: Helge Deller <deller@gmx.de>,
linux-parisc <linux-parisc@vger.kernel.org>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Subject: Re: [PATCH v3] parisc: Fix spinlock barriers
Date: Sun, 19 Jul 2020 13:06:18 -0400 [thread overview]
Message-ID: <b055db44-681f-73a9-4b37-9fa3fdeb7ed3@bell.net> (raw)
In-Reply-To: <c100c26e-831e-6d65-ec2c-ba42b881f5c7@gmx.de>
On 2020-07-19 12:35 p.m., Helge Deller wrote:
>> In reviewing the atomic operations in entry.S, I realized that there is also a bug in the
>> spin lock release code of the TLB handler. Space id's are 64 bits on 64-bit targets. So,
>> using the least significant 32 bits to reset the spin lock is not safe. The lock will not
>> be freed if the bits are all zero.
> Hmm..
> The space ids on 64-bit Linux are limited to (see arch/parisc/mm/init.c):
> #define NR_SPACE_IDS 262144
> and SID == 0 can't happen for userspace (it's blocked in the space_id[] bitmap).
> So, I think this part was ok.
Okay, then the change to store 1 was unnecessary.
>
>> @@ -467,10 +466,9 @@
>> /* Release pa_tlb_lock lock without reloading lock address. */
>> .macro tlb_unlock0 spc,tmp,tmp1
>> #ifdef CONFIG_SMP
>> + ldi 1,\tmp1
>> 98: or,COND(=) %r0,\spc,%r0
>> - LDCW 0(\tmp),\tmp1
>> - or,COND(=) %r0,\spc,%r0
>> - stw \spc,0(\tmp)
>> + stw \tmp1,0(\tmp)
>> 99: ALTERNATIVE(98b, 99b, ALT_COND_NO_SMP, INSN_NOP)
> In tlb_lock() we only lock for non-kernel SIDs (!=0),
> but now you unlock unconditionally.
No, there's still an "or" instruction to nullify the store used to release the lock. I will go back to using the
\spc register as this is time critical code. I will add a note regarding the number of space id's.
Dave
--
John David Anglin dave.anglin@bell.net
prev parent reply other threads:[~2020-07-19 18:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-19 14:34 [PATCH v3] parisc: Fix spinlock barriers John David Anglin
2020-07-19 16:35 ` Helge Deller
2020-07-19 17:06 ` 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=b055db44-681f-73a9-4b37-9fa3fdeb7ed3@bell.net \
--to=dave.anglin@bell.net \
--cc=James.Bottomley@HansenPartnership.com \
--cc=deller@gmx.de \
--cc=linux-parisc@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.