| Message ID | Pine.LNX.4.64.0902061313260.6241@axis700.grange (mailing list archive) |
|---|---|
| State | Deferred |
| Delegated to: | Paul Mundt |
| Headers | show |
On Fri, 6 Feb 2009 13:22:33 +0100 (CET) Guennadi Liakhovetski <lg@denx.de> wrote: > This loop and test in bitmap_find_free_region() > > for (pos = 0; pos < bits; pos += (1 << order)) > if (__reg_op(bitmap, pos, order, REG_OP_ISFREE)) > break; > if (pos == bits) > return -ENOMEM; > > can only return an error (-ENOMEM) if bits is a multiple of (1 << order), > which is, for instance, true, if bits is (also) a power of 2. This > is not necessarily the case with dma_alloc_from_coherent(). A failure to > recognise too large a request leads in dma_alloc_from_coherent() to > accessing beyond available memory, and to writing beyond the bitmap. > Do we have any reports of dma_alloc_from_coherent() actually behaving in that way? > --- > > diff --git a/lib/bitmap.c b/lib/bitmap.c > index 1338469..d49c37f 100644 > --- a/lib/bitmap.c > +++ b/lib/bitmap.c > @@ -953,7 +953,7 @@ int bitmap_find_free_region(unsigned long *bitmap, int bits, int order) > for (pos = 0; pos < bits; pos += (1 << order)) > if (__reg_op(bitmap, pos, order, REG_OP_ISFREE)) > break; > - if (pos == bits) > + if (pos + (1 << order) > bits) > return -ENOMEM; > __reg_op(bitmap, pos, order, REG_OP_ALLOC); > return pos; -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 6 Feb 2009, Andrew Morton wrote: > On Fri, 6 Feb 2009 13:22:33 +0100 (CET) > Guennadi Liakhovetski <lg@denx.de> wrote: > > > This loop and test in bitmap_find_free_region() > > > > for (pos = 0; pos < bits; pos += (1 << order)) > > if (__reg_op(bitmap, pos, order, REG_OP_ISFREE)) > > break; > > if (pos == bits) > > return -ENOMEM; > > > > can only return an error (-ENOMEM) if bits is a multiple of (1 << order), > > which is, for instance, true, if bits is (also) a power of 2. This > > is not necessarily the case with dma_alloc_from_coherent(). A failure to > > recognise too large a request leads in dma_alloc_from_coherent() to > > accessing beyond available memory, and to writing beyond the bitmap. > > > > Do we have any reports of dma_alloc_from_coherent() actually behaving > in that way? Does this count: http://marc.info/?l=linux-kernel&m=123313185800954&w=2 Yes, I did see this behaviour with a video driver, that's still not in the mainline (expected in the next cycle), using videobuf-dma-contig.c in the __videobuf_mmap_mapper() function. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/lib/bitmap.c b/lib/bitmap.c index 1338469..d49c37f 100644 --- a/lib/bitmap.c +++ b/lib/bitmap.c @@ -953,7 +953,7 @@ int bitmap_find_free_region(unsigned long *bitmap, int bits, int order) for (pos = 0; pos < bits; pos += (1 << order)) if (__reg_op(bitmap, pos, order, REG_OP_ISFREE)) break; - if (pos == bits) + if (pos + (1 << order) > bits) return -ENOMEM; __reg_op(bitmap, pos, order, REG_OP_ALLOC); return pos;
This loop and test in bitmap_find_free_region() for (pos = 0; pos < bits; pos += (1 << order)) if (__reg_op(bitmap, pos, order, REG_OP_ISFREE)) break; if (pos == bits) return -ENOMEM; can only return an error (-ENOMEM) if bits is a multiple of (1 << order), which is, for instance, true, if bits is (also) a power of 2. This is not necessarily the case with dma_alloc_from_coherent(). A failure to recognise too large a request leads in dma_alloc_from_coherent() to accessing beyond available memory, and to writing beyond the bitmap. Signed-off-by: Guennadi Liakhovetski <lg@denx.de> --- -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html