Re: %u-order allocation failed

[Mikulas Patocka]

> >OK, but my patch uses vmalloc only as a fallback when buddy fails. The
> >probability that buddy fails is small. It is slower but with very small
> >probability.
> >
> >It is perfectly OK to have a bit slower access to task_struct with
> >probability 1/1000000.
> >
> >But it is ***BAD*BUG*** if allocation of task_struct fails with
> >probability 1/1000000.
> 
> I missed the beginning of the thread, sorry if that question was
> already answered,
> 
> What about all the code that still consider kmalloc'ed memory is
> safe for use with virt_to_bus and friends and is contiguous
> physically for DMA ? In some cases (non-PCI devices, embedded
> platforms, etc...), the pci_consistent API is not an option.
> That means that __GFP_VMALLOC can't be part of GFP_KERNEL or
> many driver will break in horrible ways (random memory corruption).

You are right. Code that allocates more than page and expects it to be
physicaly contignuous is broken by design. Even rewrite the driver or
allocate memory on boot. It will be very hard to audit all drivers for it.

Mikulas