On Fri, Jan 10, 2014 at 05:48:55PM +0900, Joonsoo Kim wrote: > On Thu, Jan 09, 2014 at 09:27:20AM +0000, Mel Gorman wrote: > > On Thu, Jan 09, 2014 at 04:04:40PM +0900, Joonsoo Kim wrote: > > > Hello, > > > > > > I found some weaknesses on handling migratetype during code review and > > > testing CMA. > > > > > > First, we don't have any synchronization method on get/set pageblock > > > migratetype. When we change migratetype, we hold the zone lock. So > > > writer-writer race doesn't exist. But while someone changes migratetype, > > > others can get migratetype. This may introduce totally unintended value > > > as migratetype. Although I haven't heard of any problem report about > > > that, it is better to protect properly. > > > > > > > This is deliberate. The migratetypes for the majority of users are advisory > > and aimed for fragmentation avoidance. It was important that the cost of > > that be kept as low as possible and the general case is that migration types > > change very rarely. In many cases, the zone lock is held. In other cases, > > such as splitting free pages, the cost is simply not justified. > > > > I doubt there is any amount of data you could add in support that would > > justify hammering the free fast paths (which call get_pageblock_type). > > Hello, Mel. > > There is a possibility that we can get unintended value such as 6 as > migratetype > if reader-writer (get/set pageblock_migratetype) race happends. It can be > possible, because we read the value without any synchronization method. And > this migratetype, 6, has no place in buddy freelist, so array index overrun > can > be possible and the system can break, although I haven't heard that it occurs. > > I think that my solution is too expensive. However, I think that we need > solution. aren't we? Do you have any better idea? >
It's not something I have ever heard or seen of occurring but if you've identified that it's a real possibility then split get_pageblock_migratetype into locked and unlocked versions. Ensure that calls to set_pageblock_migratetype is always under zone->lock and get_pageblock_migratetype is also under zone->lock which both should be true in the majority of cases. Use the unlocked version otherwise but instead of synchronoing, check if it's returning >= MIGRATE_TYPES and return MIGRATE_MOVABLE in the unlikely event of a race. This will avoid harming the fast paths for the majority of users and limit the damage if a MIGRATE_CMA region is accidentally treated as MIGRATe_MOVABLE -- Mel Gorman SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
