On 10/10/2010 01:59 PM, Andi Kleen wrote: > DM-CRYPT: Scale to multiple CPUs v3 > > [Due to popular demand this is a port of the dm-crypt scalability > patch to 2.6.36-rc7. The 2.6.35 and .32 patches were widely used by > lots of users with good results. > Hi Andi, please can you check split patches in http://mbroz.fedorapeople.org/dm-crypt/2.6.36-devel/ is there some change in your new version? Can I send this to dm-devel instead? (It is better for review.) I know that I fixed some small bug there and these are heavily tested by me. Alasdair, _please_ can you include it in dm-tree? I asked you at least 5 times already, my last info is that you are planning this for 2.6.37, right? > static void kcryptd_queue_io(struct dm_crypt_io *io) > { > - struct crypt_config *cc = io->target->private; > + int cpu; > + > + /* > + * Since we only have a single worker per CPU in extreme > + * cases there might be nesting (dm-crypt on another dm-crypt) > + * To avoid deadlock run the work directly then. > + */ > + cpu = get_cpu(); > + if (per_cpu(io_wq_cpu, cpu) == current && !in_interrupt()) { > + put_cpu(); > + kcryptd_io(&io->work); > + return; > + } This is only place where I see problem - if running in crypto async mode, callback is called in interrupt mode (please correct me if I am wrong). So with async crypto and nested dm-crypt mapping this deadlock prevention doesn't work - so is there still possibility of deadlock? (I think we can ignore it for now, I tried create some "real world" deadlocky mappings some time ago and was not able to catch it even on high memory pressure.) Milan -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
