On Tue, Jun 9, 2009 at 12:29 PM, Hiroshi DOYU<Hiroshi.DOYU@xxxxxxxxx> wrote: > From: ext Felipe Contreras <felipe.contreras@xxxxxxxxx> > Subject: Re: [PATCH] DSPBRIDGE: Compiler wanrning fix for unlocked_ioctl > Date: Tue, 9 Jun 2009 11:16:52 +0200 > >> On Tue, Jun 9, 2009 at 10:02 AM, Hiroshi DOYU<Hiroshi.DOYU@xxxxxxxxx> wrote: >> > From: "ext Kanigeri, Hari" <h-kanigeri2@xxxxxx> >> > Subject: RE: [PATCH] DSPBRIDGE: Compiler wanrning fix for unlocked_ioctl >> > Date: Mon, 8 Jun 2009 22:49:21 +0200 >> > >> >> Hi Doyu-san, >> >> >> >> Regarding >> >> >> >> > http://marc.info/?l=linux-omap&m=124201773423892&w=2 >> >> > I think that the first one should be merged into d.o-z.org now, but >> >> > for the second one about 128 byte alignment. let me know your >> >> > thought/plan on it. >> >> >> >> -- I think you sent this patch as a probable fix for the slab >> >> corruption that was observed in Bridge driver, but then we found >> >> that slab corruption was due to some other issue in Bridge driver >> >> and not due to the cache alignment. >> >> >> >> Irrespective of above point, I think it is good to enforce the cache >> >> alignment check, but I think the check should be in Proc Map >> >> function and to start with the check should be under a flag so as >> >> not to affect some MM applications that use padding to get over the >> >> alignment issue. >> > >> > I think that having configurable option may be reasonable practically, >> > at the moment. >> > >> > But how about the longer term solution? Do you have any plan on how to >> > deal with this? (ex: TI's OMX layer and some other userland client) Do >> > you continue the userland buffer padding solution for the futer >> > release? >> >> I don't know about TI's OMX layer, but I'm working on some direct >> GStreamer wrappers that already do the proper alignment. > > I expect that it will bring huge performance benfit. You mean because of the alignment or because of the implementation? In any case, you are correct :) >> My plan currently is to keep working on gst-dsp until we have all the >> elements we need. After that's done we will be able to turn on the >> check in the kernel. >> >> Then, if I have time I might port the changes to TI's omx il. > > Both would be necessary for real products. IMHO much more would be necessary for real products. Right now the DSP SW can read/write any location of memory (security risk?), I think all the memory should be protected and then the bridgedriver should give the DSP permissions on certain memory areas. -- 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
