> 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
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
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
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
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
Maxime Villard writes:
> Can we do something about it now? It's been more than a week, and the issue is
> still there. NVMM still doesn't modload, same for procfs, and GENERIC_KASLR
> doesn't work either.
>
> This needs to be fixed now, and we should not start adding random hacks all
> over the
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
> 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
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
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
> 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
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
(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 kernel panic due to alignment fault on
14 matches
Mail list logo
