On Thu, Feb 18, 2010 at 03:40:49PM +0100, Ameya Palande wrote: > This patch series splits DMM_RES_OBJECT into DMM_MAP_OBJECT and DMM_RSV_OBJECT > which are used independently for mapped and reserved memory resources > accounting. This will help in cleanup of reserved memory resources which was > not handled properly before. With these patches resource cleanup mechanism > will work perfectly in a use case where a big chunk of memory is reserved and > then lot of mappings are created inside it. > > Changes since v4: > 1. Replace unnecessary list_for_each_entry_safe to list_for_each_entry > http://marc.info/?l=linux-omap&m=126645721715598&w=2 > 2. Comments at appropriate places to explain resource tracking objects > insertion and removals. > http://marc.info/?l=linux-omap&m=126649541624172&w=2 > > Changes since v3: > 1. Improved mapped memory resource cleanup > > Changes since v2: > 1. Removed locking from DRV_RemoveAllDMMResElements() > 2. Removed cleanup variable from PROC_UnReserveMemory() > http://marc.info/?l=linux-omap&m=126637211831587&w=2 > 3. Rebased patchset on top of following commit: > DSPBRIDGE: Remove conditional check from the InputMsg function > > Changed since v1: > 1. Reduced indentation > http://marc.info/?l=linux-omap&m=126624982331523&w=2 > > Ameya Palande (4): > DSPBRIDGE: Rename DMM_RES_OBJECT to DMM_MAP_OBJECT > DSPBRIDGE: New reserved memory accounting framework > DSPBRIDGE: Fix memory corruption in DRV_ProcFreeDMMRes > DSPBRIDGE: Improved mapped memory cleanup I'm not entirely happy with this order, I generally prefer: 1) critical fixes (fix memory corruption) 2) reorganization 3) new feature (fix res object leakage) This way the critical fixes can be merged first, while the rest of the patches are worked on. And reorganization usually don't have much problem going in. Currently in your patch #2 the spinlocks protection is not symmetrical between map and res. But in general they look ok: Reviwed-by: Felipe Contreras <felipe.contreras@xxxxxxxxx> -- 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
