[lkml]   [2001]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: %u-order allocation failed
> >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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:04    [W:0.052 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site