linux-kernel - Re: [PATCH] staging: Disable lustre file system for MIPS, SH, and XTENSA

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 11 Sep 2013 20:48:39 +0000
From:	"Dilger, Andreas" <andreas.dilger@...el.com>
To:	Peng Tao <bergwolf@...il.com>,
	Christoph Hellwig <hch@...radead.org>
CC:	Heiko Carstens <heiko.carstens@...ibm.com>,
	Guenter Roeck <linux@...ck-us.net>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>
Subject: Re: [PATCH] staging: Disable lustre file system for MIPS, SH, and
 XTENSA

On 2013/09/10 8:25 PM, "Peng Tao" <bergwolf@...il.com> wrote:

>On Wed, Sep 11, 2013 at 9:44 AM, Christoph Hellwig <hch@...radead.org>
>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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/