From: David Laight <David.Laight@ACULAB.COM>
To: 'Guo Ren' <guoren@kernel.org>
Cc: Leonardo Bras <leobras@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"paul.walmsley@sifive.com" <paul.walmsley@sifive.com>,
"palmer@dabbelt.com" <palmer@dabbelt.com>,
"alexghiti@rivosinc.com" <alexghiti@rivosinc.com>,
"charlie@rivosinc.com" <charlie@rivosinc.com>,
"xiao.w.wang@intel.com" <xiao.w.wang@intel.com>,
"david@redhat.com" <david@redhat.com>,
"panqinglin2020@iscas.ac.cn" <panqinglin2020@iscas.ac.cn>,
"rick.p.edgecombe@intel.com" <rick.p.edgecombe@intel.com>,
"willy@infradead.org" <willy@infradead.org>,
"bjorn@rivosinc.com" <bjorn@rivosinc.com>,
"conor.dooley@microchip.com" <conor.dooley@microchip.com>,
"cleger@rivosinc.com" <cleger@rivosinc.com>,
"linux-riscv@lists.infradead.org"
<linux-riscv@lists.infradead.org>,
Guo Ren <guoren@linux.alibaba.com>
Subject: RE: [PATCH V2 4/4] riscv: mm: Optimize TASK_SIZE definition
Date: Sun, 24 Dec 2023 14:37:54 +0000 [thread overview]
Message-ID: <794c14d6c979495e869d7ba03a935e3b@AcuMS.aculab.com> (raw)
In-Reply-To: <CAJF2gTQjixePmc8qNJZB+kfyzjVb+NqFHR6GOow-aNhN883CQA@mail.gmail.com>
From: Guo Ren
> Sent: 24 December 2023 01:24
...
> > One possibility would be to save the task's max user address
> > in the task structure itself - that would save all the conditionals
> > at a cost of an extra value in the task structure.
> It would still cause memory load operation, although it is $tp->xxx.
All the (mispredicted) branches are likely to cause more of a
problem than a load from the current task structure.
> If we want to gain observability benefits, "just check (ptr | (ptr +
> len)) < 0)" is better.
If you can guarantee a faulting page between user and kernel addresses
and assume (check) that the accesses are 'reasonably sequential'
then you only need to check the base address.
That is likely hard for 32bit but easier for 64bit (except arm64)
because A63 and A62 have to match.
Unless you have some hardware address masking which makes it much
more likely that 'random values' will be valid addresses.
(Someone remind me why that is a good idea unless the high bits
are validated by the hardware.)
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
prev parent reply other threads:[~2023-12-24 14:38 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-21 15:46 [PATCH V2 0/4] riscv: mm: Fixup & Optimize COMPAT code guoren
2023-12-21 15:46 ` [PATCH V2 1/4] riscv: mm: Fixup compat mode boot failure guoren
2023-12-22 1:51 ` Leonardo Bras
2023-12-22 2:57 ` Guo Ren
2023-12-22 3:50 ` Charlie Jenkins
2023-12-22 4:32 ` Leonardo Bras
2023-12-22 7:33 ` Guo Ren
2023-12-22 10:58 ` Guo Ren
2023-12-21 15:46 ` [PATCH V2 2/4] riscv: mm: Fixup compat arch_get_mmap_end guoren
2023-12-22 3:34 ` Leonardo Bras
2023-12-22 4:04 ` Charlie Jenkins
2023-12-22 4:23 ` Leonardo Bras
2023-12-22 5:42 ` Charlie Jenkins
2023-12-22 8:27 ` Leonardo Bras
2023-12-22 4:36 ` Guo Ren
2023-12-22 4:26 ` Guo Ren
2023-12-22 4:43 ` Leonardo Bras
2023-12-22 4:50 ` Guo Ren
2023-12-22 5:27 ` Leonardo Bras
2023-12-22 7:20 ` Guo Ren
2023-12-22 7:49 ` Leonardo Bras
2023-12-22 8:59 ` David Laight
2023-12-22 9:33 ` Guo Ren
2023-12-21 15:47 ` [PATCH V2 3/4] riscv: mm: Remove unused TASK_SIZE_MIN guoren
2023-12-22 4:49 ` Leonardo Bras
2023-12-22 7:16 ` Guo Ren
2023-12-22 7:22 ` Leonardo Bras
2023-12-21 15:47 ` [PATCH V2 4/4] riscv: mm: Optimize TASK_SIZE definition guoren
2023-12-22 5:09 ` Leonardo Bras
2023-12-22 11:25 ` Guo Ren
2023-12-22 11:52 ` David Laight
2023-12-23 2:38 ` Guo Ren
2023-12-23 2:52 ` Guo Ren
2023-12-23 10:31 ` David Laight
2023-12-24 1:24 ` Guo Ren
2023-12-24 14:37 ` David Laight [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=794c14d6c979495e869d7ba03a935e3b@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=alexghiti@rivosinc.com \
--cc=bjorn@rivosinc.com \
--cc=charlie@rivosinc.com \
--cc=cleger@rivosinc.com \
--cc=conor.dooley@microchip.com \
--cc=david@redhat.com \
--cc=guoren@kernel.org \
--cc=guoren@linux.alibaba.com \
--cc=leobras@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=panqinglin2020@iscas.ac.cn \
--cc=paul.walmsley@sifive.com \
--cc=rick.p.edgecombe@intel.com \
--cc=willy@infradead.org \
--cc=xiao.w.wang@intel.com \
/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
all inboxes | Powered by JetHome®