On 2019/01/08 17:33, Nick Hudson wrote:
On 07/01/2019 10:22, Rin Okuyama wrote:
[snip]
This kind of problems cannot be handled in software unless we
(1) use cached memory (for which unaligned access is allowed), or
(2) forbid compiler to generate unaligned access.
This patch
On 07/01/2019 10:22, Rin Okuyama wrote:
[snip]
This kind of problems cannot be handled in software unless we
(1) use cached memory (for which unaligned access is allowed), or
(2) forbid compiler to generate unaligned access.
This patch
http://www.netbsd.org/~rin/armv6_cached
On 2019/01/07 10:59, matthew green wrote:
http://netbsd.org/~kamil/kubsan/0007-boot-real-hardware.txt
i fixed the hdafg.c ones here. not sure about the hdaudio.c
ones, since they are already 1u << 31. leaving:
x86/pci/pci_machdep.c
ahcisata_core.c
amd64/kobj_machdep.c
netinet/tcp_input.c
be
> http://netbsd.org/~kamil/kubsan/0007-boot-real-hardware.txt
i fixed the hdafg.c ones here. not sure about the hdaudio.c
ones, since they are already 1u << 31. leaving:
x86/pci/pci_machdep.c
ahcisata_core.c
amd64/kobj_machdep.c
netinet/tcp_input.c
beyond the xhci one, that actually doesn't ma
On Jan 6, 9:53am, nick.hud...@gmx.co.uk (Nick Hudson) wrote:
-- Subject: Re: Unaligned access in kernel on ARMv6+ (Re: CVS commit: src/sys
| I'm pretty sure this is the same as http://gnats.netbsd.org/50038
Yes, this looks like the same issue; we should not be patching individual
drivers like th
On Jan 6, 3:59pm, nick.hud...@gmx.co.uk (Nick Hudson) wrote:
-- Subject: Re: Unaligned access in kernel on ARMv6+ (Re: CVS commit: src/sys
| > Isn't that orthogonal?
|
| Nope, because normal cached memory allows unaligned access (kernel and
| userland).
|
I did not realize that the i_axe case
On 06/01/2019 15:31, Christos Zoulas wrote:
On Jan 6, 9:53am, nick.hud...@gmx.co.uk (Nick Hudson) wrote:
-- Subject: Re: Unaligned access in kernel on ARMv6+ (Re: CVS commit: src/sys
| I'm pretty sure this is the same as http://gnats.netbsd.org/50038
Yes, this looks like the same issue; we
On Jan 6, 5:46pm, rokuy...@rk.phys.keio.ac.jp (Rin Okuyama) wrote:
-- Subject: Unaligned access in kernel on ARMv6+ (Re: CVS commit: src/sys/dev
| I guess other codes can be miscompiled if -mno-unaligned-access is
| not specified. Can I commit the patch?
I believe this is the right way to do it,
kUBSan detected a number of unaligned accesses in USB code:
http://netbsd.org/~kamil/kubsan/0007-boot-real-hardware.txt
On 06.01.2019 09:46, Rin Okuyama wrote:
> (CC added to port-...@netbsd.org)
>
> Let me summarize the problem briefly. In axe(4), there is a code where
> memcpy() is carried out
On Sun, Jan 06, 2019 at 05:52:55AM -0800, Jason Thorpe wrote:
> That's probably a good idea in any case, because there will almost
> certainly be a performance benefit, but I still think ensuring that
> drivers don't perform unaligned accesses is desirable.
It is a bit tricky. We do this only when
> On Jan 6, 2019, at 5:36 AM, Martin Husemann wrote:
>
> On Sun, Jan 06, 2019 at 08:31:53AM -0500, Greg Troxel wrote:
>> Why do we generate code with unaligned access in user space? That seems
>> surprising, if the processor isn't happy about it.
>
> The processor is happy with it, both in u
On Sun, Jan 06, 2019 at 08:31:53AM -0500, Greg Troxel wrote:
> Why do we generate code with unaligned access in user space? That seems
> surprising, if the processor isn't happy about it.
The processor is happy with it, both in user- and kernel space.
Only special memory regions mapped uncached m
matthew green writes:
>> In short, this is because -munaligned-access is enabled on ARMv6+ by
>> default for GCC. As the unaligned memory access is forbidden in the
>> supervisor mode unlike in the user mode, we need to explicitly specify
>> -mno-unaligned-access for kernel on ARMv6+.
>
> i think
> In short, this is because -munaligned-access is enabled on ARMv6+ by
> default for GCC. As the unaligned memory access is forbidden in the
> supervisor mode unlike in the user mode, we need to explicitly specify
> -mno-unaligned-access for kernel on ARMv6+.
i think this seems like the right thin
On 06/01/2019 08:46, Rin Okuyama wrote:
(CC added to port-...@netbsd.org)
Let me summarize the problem briefly. In axe(4), there is a code where
memcpy() is carried out from 2-byte aligned buffer to 4-byte structure:
https://nxr.netbsd.org/xref/src/sys/dev/usb/if_axe.c#1284
This results in ker
15 matches
Mail list logo
