Am 08.12.2016 um 11:33 schrieb Michal Hocko:
From: Michal Hocko <mhocko@xxxxxxxx>
Using kmalloc with the vmalloc fallback for larger allocations is a
common pattern in the kernel code. Yet we do not have any common helper
for that and so users have invented their own helpers. Some of them are
really creative when doing so. Let's just add kv[mz]alloc and make sure
it is implemented properly. This implementation makes sure to not make
a large memory pressure for > PAGE_SZE requests (__GFP_NORETRY) and also
to not warn about allocation failures. This also rules out the OOM
killer as the vmalloc is a more approapriate fallback than a disruptive
user visible action.
This patch also changes some existing users and removes helpers which
are specific for them. In some cases this is not possible (e.g.
ext4_kvmalloc, libcfs_kvzalloc, __aa_kvmalloc) because those seems to be
broken and require GFP_NO{FS,IO} context which is not vmalloc compatible
in general (note that the page table allocation is GFP_KERNEL). Those
need to be fixed separately.
apparmor has already claimed kv[mz]alloc so remove those and use
__aa_kvmalloc instead to prevent from the naming clashes.
Cc: Paolo Bonzini <pbonzini@xxxxxxxxxx>
Cc: Mike Snitzer <snitzer@xxxxxxxxxx>
Cc: dm-devel@xxxxxxxxxx
Cc: "Michael S. Tsirkin" <mst@xxxxxxxxxx>
Cc: "Theodore Ts'o" <tytso@xxxxxxx>
Cc: kvm@xxxxxxxxxxxxxxx
Cc: linux-ext4@xxxxxxxxxxxxxxx
Cc: linux-f2fs-devel@xxxxxxxxxxxxxxxxxxxxx
Cc: linux-security-module@xxxxxxxxxxxxxxx
Signed-off-by: Michal Hocko <mhocko@xxxxxxxx>
I remember yet another similar user in arch/s390/kvm/kvm-s390.c
-> kvm_s390_set_skeys()
...
keys = kmalloc_array(args->count, sizeof(uint8_t),
GFP_KERNEL | __GFP_NOWARN);
if (!keys)
vmalloc(sizeof(uint8_t) * args->count);
...
would kvmalloc_array make sense? (it would even make the code here
less error prone and better to read)
--
David
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
