Hi Phil, This can break because copy_from/to_user() copies from the current user process (which should be obvious, since there's no way to tell it which user process to copy from).
In a syscall invoked by your userspace process this is OK, because the current process is your userspace process. However, within the kernel thread (as in worker thread) the current process could be any other process on the system - so one may be copying from a random process's memory, which is why garbage can be written in physical memory. Regards Yashpal > -----Original Message----- > From: cryptodev-linux-devel-boun...@gna.org [mailto:cryptodev-linux- > devel-boun...@gna.org] On Behalf Of Phil Sutter > Sent: Friday, February 15, 2013 6:42 AM > To: cryptodev-linux-devel@gna.org > Subject: Re: [Cryptodev-linux-devel] Asynchronous support in Cryptodev is > buggy > > Hi, > > On Thu, Feb 14, 2013 at 05:20:07PM +0000, Dutta Yashpal-B05456 wrote: > > Looked at asynchronous support in Cryptodev-1.5 and found that it is > > getting in following flow cryptask_routine calling crypto_run. Now in > > crypto_run API, all the user-space process provided buffers are either > > being copied to kernel buffers or they are being mapped in kernel using > get_user_pages. > > > > Either way it is wrong because by the time cryptask_routine is > > executing, it is running in work_queue kernel thread context and not > > in process context. So, these user-space buffer are not accessible in > work-queue Context. In my view, asynchronous support needs to be fixed. > > Have you tested this? It's working fine! Prove it wrong, then I'll take > care of it. :) > > Greetings, Phil > > _______________________________________________ > Cryptodev-linux-devel mailing list > Cryptodev-linux-devel@gna.org > https://mail.gna.org/listinfo/cryptodev-linux-devel _______________________________________________ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel
