On Mon, May 11, 2009 at 7:26 PM, Kanigeri, Hari <[email protected]> wrote: > Hi Doyu-san, > >> >> Hi Hari, >> >> From: "ext Kanigeri, Hari" <[email protected]> >> 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
