From: Al Viro <viro@ZenIV.linux.org.uk>
To: linux-ia64@vger.kernel.org
Cc: linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Tony Luck <tony.luck@intel.com>,
Fenghua Yu <fenghua.yu@intel.com>
Subject: Re: ia64 exceptions (Re: [RFC][CFT][PATCHSET v1] uaccess unification)
Date: Wed, 5 Apr 2017 09:08:57 +0100 [thread overview]
Message-ID: <20170405080857.GR29622@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20170405050507.GQ29622@ZenIV.linux.org.uk>
On Wed, Apr 05, 2017 at 06:05:08AM +0100, Al Viro wrote:
> Speaking of ia64: copy_user.S contains the following oddity:
> 2:
> EX(.failure_in3,(p16) ld8 val1[0]=[src1],16)
> (p16) ld8 val2[0]=[src2],16
>
> src1 is 16-byte aligned, src2 is src1 + 8.
>
> What guarantees that we can't race with e.g. TLB shootdown from a thread on
> another CPU, ending up with the second insn taking a fault and oopsing?
>
> AFAICS, other places where we have such pairs of loads or stores (e.g.
> EX(.ex_handler, (p16) ld8 r34=[src0],16)
> EK(.ex_handler, (p16) ld8 r38=[src1],16)
> in the memcpy_mck.S counterpart of that code) both have exception table
> entries associated with them.
>
> Is that one intentional and correct for some subtle reason, or is it a very
> narrow race on the hardware nobody gives a damn anymore? It is pre-mckinley
> stuff, after all...
Actually, the piece immediately after that one is worse. By that point,
we have
* checked that len is large enough to be worth bothering with word
copies. Fine.
* checked that src and dst have the same remainder modulo 8.
* copied until src is a multiple of 16, incrementing src and dst
by the same amount.
* prepared for copying in multiples of 16 bytes
* set src2 and dst2 8 bytes past src1 and dst1 resp.
and now we have a pipelined loop with
EX(.failure_in3,(p16) ld8 val1[0]=[src1],16)
(p16) ld8 val2[0]=[src2],16
EX(.failure_out, (EPI) st8 [dst1]=val1[PIPE_DEPTH-1],16)
(EPI) st8 [dst2]=val2[PIPE_DEPTH-1],16
for body. Now, consider the following case:
* to is 8 bytes before the end of user page, next page is unmapped
* from is at the beginning of kernel page
* len is simply PAGE_SIZE
and we call copy_to_user(). All the preparation work won't read or write
anything - all alignments are fine. src1 and src2 are kernel page and
kernel page + 8 resp.; dst1 is 8 bytes before the end of user page, dst2
is at the beginning of unmapped user page. No loads are going to fail;
the first store into dst1 won't fail either. The *second* store - one to
dst2 will not just fail, it'll oops.
<goes to test>
... and sure enough, on generic kernel (CONFIG_ITANIUM) that yields a nice
shiny oops at precisely that insn.
We really need tests for uaccess primitives. That's not a recent regression,
BTW - it had been that way since 2.3.48-pre2, as far as I can see.
next prev parent reply other threads:[~2017-04-05 8:09 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-29 5:57 [RFC][CFT][PATCHSET v1] uaccess unification Al Viro
2017-03-29 20:08 ` Vineet Gupta
2017-03-29 20:29 ` Al Viro
2017-03-29 20:37 ` Linus Torvalds
2017-03-29 21:03 ` Al Viro
2017-03-29 21:24 ` Linus Torvalds
2017-03-29 23:09 ` Al Viro
2017-03-29 23:43 ` Linus Torvalds
2017-03-30 15:31 ` Al Viro
2017-03-29 21:14 ` Vineet Gupta
2017-03-29 23:42 ` Al Viro
2017-03-30 0:02 ` Vineet Gupta
2017-03-30 0:27 ` Linus Torvalds
2017-03-30 1:15 ` Al Viro
2017-03-30 20:40 ` Vineet Gupta
2017-03-30 20:59 ` Linus Torvalds
2017-03-30 23:21 ` Russell King - ARM Linux
2017-03-30 12:32 ` Martin Schwidefsky
2017-03-30 14:48 ` Al Viro
2017-03-30 16:22 ` Russell King - ARM Linux
2017-03-30 16:43 ` Al Viro
2017-03-30 17:18 ` Linus Torvalds
2017-03-30 18:48 ` Al Viro
2017-03-30 18:54 ` Al Viro
2017-03-30 18:59 ` Linus Torvalds
2017-03-30 19:10 ` Al Viro
2017-03-30 19:19 ` Linus Torvalds
2017-03-30 21:08 ` Al Viro
2017-03-30 18:56 ` Linus Torvalds
2017-03-31 0:21 ` Kees Cook
2017-03-31 13:38 ` James Hogan
2017-04-03 16:27 ` James Morse
2017-04-04 20:26 ` Max Filippov
2017-04-04 20:52 ` Al Viro
2017-04-05 5:05 ` ia64 exceptions (Re: [RFC][CFT][PATCHSET v1] uaccess unification) Al Viro
2017-04-05 8:08 ` Al Viro [this message]
2017-04-05 18:44 ` Tony Luck
2017-04-05 20:33 ` Al Viro
2017-04-07 0:24 ` [RFC][CFT][PATCHSET v2] uaccess unification Al Viro
2017-04-07 0:35 ` Al Viro
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=20170405080857.GR29622@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=fenghua.yu@intel.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tony.luck@intel.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).