ch/x86/x86/pmap.c"
>
There is a number of similar reports on syzbot.
> Looks like radixtree.c doesn't handle allocation failures very well
> somewhere.
>
> fault(4) seems like the kind of feature that would be useful for
> stress-testing
> and fuzzing. As you can see in
> Date: Sat, 8 Feb 2020 06:19:43 -0800 (PST)
> From: Paul Goyette
>
> If this is a device on which you can use ioctl() to configure, why is
> it not stored under sys/dev and why is it not included in kernel config
> with pseudo-device directive (and corresponding files.kern changes)?
There's no
On Sat, 8 Feb 2020, Martin Husemann wrote:
On Sat, Feb 08, 2020 at 06:19:43AM -0800, Paul Goyette wrote:
The module should be MODULE_CLASS_DRIVER. And there should be a
sys/module/fault/Makefile to build the module, along with changes to
sys/module/Makefile (to descend into the fault
On Sat, Feb 08, 2020 at 06:19:43AM -0800, Paul Goyette wrote:
> The module should be MODULE_CLASS_DRIVER. And there should be a
> sys/module/fault/Makefile to build the module, along with changes to
> sys/module/Makefile (to descend into the fault directory) and to
>
]
In order to explore error branches, and to test the kernel's ability to cope
with failures, it is often necessary to hard-trigger such failures.
Here is an implementation [1] for fault(4), a driver that allows to trigger
failures in the kernel. A similar driver exists in Linux.
The fault_inject
[I am not subscribed to this list, so if you want to answer, make sure to CC me]
In order to explore error branches, and to test the kernel's ability to cope
with failures, it is often necessary to hard-trigger such failures.
Here is an implementation [1] for fault(4), a driver that allows
