>-----Original Message----- >From: Felipe Contreras [mailto:felipe.contreras@xxxxxxxxx] >Sent: Wednesday, February 10, 2010 7:08 AM >To: Guzman Lugo, Fernando >Cc: Ameya Palande; linux-omap; Ramirez Luna, Omar; Menon, Nishanth; >Chitriki Rudramuni, Deepak; Phil Carmody >Subject: Re: [PATCH] DSPBRIDGE: Prevent memory corruption in >DRV_ProcFreeDMMRes > >On Wed, Feb 10, 2010 at 05:06:26AM +0100, ext Guzman Lugo, Fernando wrote: >> >At this point there's an obvious question; what's the point of >> >reserving a memory region and not mapping it? >> > >> >I remember the answer from Hari was: some clients prefer to reserve a >> >big region once, and map parts of it continuously. I have my doubts >> >that the use-case even works with the current code-base. But assuming >> >it does work, your proposed changes would break it. >> >> Resource cleanup does not support that even without my proposed changes. > >Aha! I suspected it :P > Resource cleanup does not support that because it tries to unreserved every chunk mapped. However it does not means the dspbridge does not support reserving a big chunk of memory and mapping small parts of that memory, but I have not tested it to confirm if it works. >> I just proposed a solution which fixes two issues in one patch. >> Moreover if this change is merged when the second issue be fixed this >> patch will not needed anymore, so why don't merge the patch which >> fixes both errors at this moment? > >simple patches > complicated patches The patch is more simple than it looks. > >Personally I think your patches should be a continuation to the patches >I just proposed. Yes, I think it would be better. Regards, Fernando. > >If nobody wants to split these patches, I'll gladly do so. > >> >+ u32 dsp_res_addr = p_cur_res->ulDSPResAddr; >> >+ >> >+ status = PROC_UnMap(p_cur_res->hProcessor, >> >+ (void *)p_cur_res->ulDSPAddr, p_ctxt); >> > >> >It would be much easier to merge the two functions into one. >> >> Yes, I am agreed. > >Good. Perhaps we can start moving reserve/unreserve functionality to >map/unmap, and eventually depreate the former. > >Cheers. > >-- >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
