Le 20/08/2018 à 21:39, Christos Zoulas a écrit :
In article <23611.1534790011%splode.eterna.com.au@localhost>,
matthew green <mrg%eterna.com.au@localhost> wrote:
"Maxime Villard" writes:
Module Name: src
Committed By: maxv
Date: Mon Aug 20 11:35:28 UTC 2018
Modified Files:
src/sys/kern: files.kern subr_kmem.c
Log Message:
Retire KMEM_REDZONE and KMEM_POISON.
KMEM_REDZONE is not very efficient and cannot detect read overflows. KASAN
can, and will be used instead.
asan requires a 64 bit system, so, i'm not really OK with
removing this code and requiring kasan.
please discuss removals like this on tech-kern first. i'd
rather this change was reverted.
Exactly: We are much more accepting on adding new features as opposed
to removing existing ones without prior discussion. Nobody is holding
a gun forcing us to remove features quickly, so a simple process like:
- announce intention to tech-kern explaining why you want to remove
something, what replaces it, and giving people a chance to comment.
- wait a few days, and remove if there was no objection.
Yes, cleanliness is a great goal, but it could be achieved without stepping
on toes.
Best,
These options were already broken until I fixed them four years ago, and _I_
enabled KMEM_REDZONE and KMEM_SIZE by default. Back when I did this, people
were not happy, because "redzones consume more memory on low-memory systems".
Later, when I improved KMEM_GUARD, KMEM_REDZONE+KMEM_POISON already became
partly obsolete, because you have better results when you unmap the next page
rather than when you poison the current one. Not to mention that KMEM_POISON
was enabled only under DEBUG -- a configuration where KMEM_GUARD is already
enabled.
Now, four years later, we do have better ways to detect overflows and
corruptions in our main architecture. The old stuff goes out, the new stuff
comes in.
Around the same time I added POOL_POISON. The code is here but has never been
enabled, and I guess I'll retire it too when I add kASan hooks to monitor
pools.