> I agree, the check should be in proc map, and should be optional. > However, I would prefer it to be an all-or-nothing option, > how about in kconfig? > -- One other way is we can use a bit mask in map attributes argument in DSP Proc Map function to enforce the check on the buffer. What are the reasons as why you want to make it all-or-nothing option ? Thank you, Best regards, Hari > -----Original Message----- > From: Felipe Contreras [mailto:felipe.contreras@xxxxxxxxx] > Sent: Monday, June 08, 2009 4:19 PM > To: Kanigeri, Hari > Cc: Hiroshi DOYU; Ramirez Luna, Omar; > ameya.palande@xxxxxxxxx; linux-omap@xxxxxxxxxxxxxxx > Subject: Re: [PATCH] DSPBRIDGE: Compiler wanrning fix for > unlocked_ioctl > > On Mon, Jun 8, 2009 at 11:49 PM, Kanigeri, > Hari<h-kanigeri2@xxxxxx> wrote: > > 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 agree, the check should be in proc map, and should be optional. > However, I would prefer it to be an all-or-nothing option, > how about in kconfig? > > -- > 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
