"Peter T. Breuer wrote:" > "Paul Clements wrote:" > > fails, and doing on-demand allocation the rest of the time? Another > > idea, expanding on what Peter has already done with marking the pointer > > with an "address" of 1 if the kmalloc fails (this means that the bitmap > > degrades from 1bit/1k to 1bit/4MB, which is not a terrible thing, all in > > all). What if we were clever and used more than just one bit when the I forgot to say that when the bitmap page fails to be allocated in order that we may mark it, then an attempted mark also fails, and the async-write code notices that and refuses to even try an async write, but stays sync instead. So this fails safe. I also forgot to say something else but I forgot what it was ... ah yes, it's that I did take care never to call kmalloc (or kfree) with the bitmap spinlock held. So that if the kernel blocks and sleeps we don't cause death. Instead we release the lock and regain it after the kmalloc, and retest the conditions that made us want to do the kmalloc then, aborting if they have been satisfied by anyone else. Indeed the kmalloc calls are only in the init function and in the function that is supposed to check the bitmap page and install a page if one is required, prior to further access. It all /looks/ under control. Peter - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
