On Mon, May 11, 2009 at 7:26 PM, Kanigeri, Hari <h-kanigeri2@xxxxxx> wrote: > Hi Doyu-san, > >> >> Hi Hari, >> >> From: "ext Kanigeri, Hari" <h-kanigeri2@xxxxxx> >> Subject: RE: [PATCH 2/2] DSPBRIDGE: add checking 128 byte alignment for >> dsp cache line size >> Date: Mon, 11 May 2009 17:09:03 +0200 >> >> > Hi Doyu-san, >> > >> > > A buffer shared with MPU and DSP has to be aligned on both cache line >> > > size to avoid memory corrupton with some DSP cache operations. Since >> > > there's no way for dspbridge to know how the shared buffer will be >> > > used like: "read-only", "write-only", "rw" through its life span, any >> > > shared buffer passed to DSP should be on this alignment. This patch >> > > adds checking those shared buffer alignement in bridgedriver cache >> > > operations and prevents userland applications from causing the above >> > > memory corruption. >> > > >> > >> > -- It looks like the buffer that are passed to the Bridge are not >> necessarily 128 byte aligned. >> > >> > This is the comment I received from Nikhil Mande (MM Engineer). >> > >> > [Nikhil Mande] "They are not necessarily "aligned" all the time. >> > Sometimes they just have 128 byte padding at the start & end of the >> buffer and the buffer pointer passed to bridge is not guaranteed to be 128 >> aligned. >> > So if you are adding such a check, it will require modifications OMX >> > components & test apps." >> >> The above means that passing unaligned address to dsp can cause memory >> corruption in kernel and this problem can be avoided only in the case >> where OMX(userland) is always supposed to pass aligned address. > > -- Why would there be memory corruption if the OMX components did the 128 bytes padding? The padding is dummy region which is not used by any other process. It's the kernel's job to enforce proper usage of memory, it should not blindly trust that user-space is doing the right thing. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
