Messages in this thread | | | Date | Sat, 27 Aug 2022 18:39:38 +0800 | Subject | Re: [PATCH -next v2 2/2] riscv: extable: add new extable type EX_TYPE_KACCESS_ERR_ZERO support | From | Tong Tiangen <> |
| |
在 2022/8/26 16:16, Andrew Jones 写道: > On Fri, Aug 26, 2022 at 02:44:48PM +0800, Tong Tiangen wrote: >> >> >> 在 2022/8/25 19:06, Andrew Jones 写道: >>> On Mon, Aug 15, 2022 at 03:20:25AM +0000, Tong Tiangen wrote: >>>> Currently, The extable type EX_TYPE_UACCESS_ERR_ZERO is used by >>>> __get/put_kernel_nofault(), but those helpers are not uaccess type, so we >>>> add a new extable type EX_TYPE_KACCESS_ERR_ZERO which can be used by >>>> __get/put_kernel_no_fault(). >>>> >>>> Only refactor code without any functional changes. >>> >>> This isn't quite true. __get/put_kernel_nofault now sets a different >>> extable type (as the commit message says). But, nothing special seems >>> to be done with that, so there's effectively no functional change. Can >>> you please elaborate on the motivation for this change? Where will the >>> KACCESS type need to be distinguished from the UACCESS type? >> >> The introduction of EX_TYPE_KACCESS_ERR_ZERO does not change any function, >> but makes a correct distinction in the actual type, indicating that there >> are indeed some kaccess entries in extable. I think this optimization is >> more clear and reasonable. > > Well, creating new types, just for new type sake, just bloats code. > >> >> A few weeks ago, I did something similar on arm64[1]. I think this >> optimization can also be used on riscv. >> >> We can do some features that are used on uaccss but not applicable on >> kaccess in the future[2]. >> >> [1] >> https://lore.kernel.org/lkml/20220621072638.1273594-2-tongtiangen@huawei.com/ >> [2]https://lore.kernel.org/lkml/20220812070557.1028499-4-tongtiangen@huawei.com/ >> > > This is part of the information, but I had already found this. What's > still missing to me are the riscv patches, or at least a riscv plan, for > actually implementing something which requires kaccess and uaccess to have > distinct types. > > Thanks, > drew
At present, there is no such plan on riscv, because it is rely on hardware support. I think this patch can be merged as a small code optimization and without any function change.
Thanks, Tong.
> > .
| |