Page sanitization, part 2
Posted Jun 5, 2009 9:39 UTC (Fri) by willezurmacht
Parent article: Page sanitization, part 2
Zijlstra and others are concerned about the price that is paid by all kernel users, even those who have not enabled sanitize_mem. He notes that the patches would add extra function calls and branches even when the feature is not enabled.
Jake, you might want to review that part of the article too (feel free to check http://en.wikipedia.org/wiki/Branch_(computer_science)). The entire SLAB/SLUB code has conditional branches and nobody ever opposed that, even though some of them could have been saved. And if they did, it would be still an anal retentive remark, since you are arguing 3 instructions more cause any noticeable or latency overhead in modern systems (or old ones at that, if you want to look at a museum). It's interesting you don't quote any of the responses to that, nor include links to the full threads of all the involved discussions. I guess the mistake wasn't intentional...
There is clearly a performance impact to clearing memory as it is reclaimed, but, since memory is cleared as it is allocated (to avoid obvious information leaks), the impact may not be as large as it seems at first glance.
The above phrasing seems quite misleading and imprecise. By reclaim you mean freeing or allocation-post-release? You've got it wrong about memory being cleared when allocated (and that it would prevent information leaks, just read the thread again skipping the bits you decided to quote here which don't add anything useful for readers to understand what's going on)... that was never done by any of the sanitization patches and they actually remove GFP_ZERO handling on allocation to avoid duplication of the clearing.
BTW, did you realize some of this made it to -mm?
Maybe you were too busy reading the sensationalist and controversial bits and missed that one too, no problem again. The article would have been great if you had actually read the patches.
to post comments)