Re: [PATCH v6 07/36] nds32: Exception handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Wed, Jan 24, 2018 at 11:53 AM, Vincent Chen <deanbo422@xxxxxxxxx> wrote:
> 2018-01-18 18:14 GMT+08:00 Arnd Bergmann <arnd@xxxxxxxx>:
>> On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu <green.hu@xxxxxxxxx> wrote:
>>> From: Greentime Hu <greentime@xxxxxxxxxxxxx>
>>>
>>> This patch includes the exception/interrupt entries, pt_reg structure and
>>> related accessors.
>>>
>>> Signed-off-by: Vincent Chen <vincentc@xxxxxxxxxxxxx>
>>> Signed-off-by: Greentime Hu <greentime@xxxxxxxxxxxxx>
>>
>> Here it would be good to have a more detailed explanation about the alignment
>> trap handling. I remember discussing it with you before, but don't remember
>> the exact outcome. In particular you should explain here why you need to
>> handle alignment traps in the first place, and what the expected defaults
>> are (e.g. always disabled unless a user requests it, or always enabled) and
>> what kind of code runs into the traps (e.g. buggy kernel code, correct
>> kernel code, buggy user space code etc).
>>
>>        Arnd
>
>
> Dear Arnd:
>
> I am plans to add the following description in the git commit's comment
>
> Andes processors cannot load/store information which is not naturally aligned
> on the bus, i.e., loading a 4 byte data whose start address must be divisible
> by 4. If unaligned data accessing is happened, data unaligned exception will be
> triggered and user will get SIGSEGV or kernel oops according to the unaligned
> address. In order to make user able to load/store data from an unaligned
> address, software load /store emulation is implemented in
> arch/nds32/mm/alignment.c to handle data unaligned exception.
>
> Unaligned accessing handling is disable by default because of it is not
> a normal case. User can follow the steps below to enable this feature.
>
> A. Compile time:
>     1. Enable kernel config CONFIG_ALIGNMENT_TRAP
> B. Run time:
>     1. Enter /proc/sys/nds32/unaligned_acess folder
>     2.
>         a. Write ‘1’ to file enable_mode to enable unaligned accessing handling
>             for user space
>         b. Write ‘2’ to file enable_mode to enable unaligned accessing handling
>             for kernel space
>         c. Write ‘3’ to file enable_mode to enable unaligned accessing handling
>             for user and kernel space
>         d. Write '0' to file enable_mode to disable all unaligned
> accessing handling
>     3.
>         a. Write ‘1’ to file debug to show which unaligned address is addressed
>         b. Write ‘0’ to file debug to disable all information
>
> However, unaligned accessing handler can’t work on following conditions.
> A. The corresponding mode for unaligned address is not enabled.
> B. This unaligned address is not accessible such as protection violation.
> On these conditions, the default behaviors for data unaligned
> exception still happen.

Ok. I still wonder about the kernel part of this though: is it a good idea
for user space to configure whether the kernel does unaligned
accesses? I would think that the kernel should just be fixed in such
a case.

     Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux