On 2013/09/10 8:25 PM, "Peng Tao" <bergwolf@xxxxxxxxx> wrote: >On Wed, Sep 11, 2013 at 9:44 AM, Christoph Hellwig <hch@xxxxxxxxxxxxx> >wrote: >> On Wed, Sep 11, 2013 at 01:14:11AM +0800, Peng Tao wrote: >>> The problem is access_process_vm() is not exported since certain >>> version of kernel including the latest. According to Christoph in the >>> other mail, access_process_vm() is also a core mm function that is not >>> supposed to be exported. Then what kind of change shall we make in >>> order to keep current functionality? >> >> You should remove the higher level functionality, kernel modules are >> not supposed to look at userspace environment variables. >> >OK. I've looked at the specific case that Lustre uses >access_process_vm() to get the jobid environment variable and package >it into the RPC requests to server. However, it turns out that in the >latest Lustre server code, the jobid in a request is not used >anywhere. So it looks like we can just get rid of it. > >Andreas, could you please confirm this? Is the jobid an obsolete >parameter that can be abandoned? Or is there plan to use it somehow in >the future? The jobid code is relatively new and in use, I'm not sure why you think it is not in use. It is actually a feature that a bunch of users requested. The jobid feature allows tracking IO request stats for parallel user processes running on possibly thousands of different client nodes onto the servers. This is easy to do with a single node and a single process via PID/PPID and blktrace or equivalent, but otherwise impossible in a parallel processing environment where there may be users running hundreds of different jobs. The PID/PPID is not consistent across client nodes, and the server threads will randomly handle requests from all users. By all means, I'd prefer to just use access_process_vm() directly, instead of making a copy in the Lustre code. Not being able to access the process environment seems a bit ridiculous - the kernel stores and manages this for the process, and it isn't even doing anything nasty like accessing the environment from a different process, just its own environment variables. Cheers, Andreas -- Andreas Dilger Lustre Software Architect Intel High Performance Data Division _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
