Hi,
Within a module I work on, I need to access to init_mm, but as it is marked
UNUSED, I wonder if there is another way (an API) to access to it.
Otherwise, what can I do to have this mark removed from init_mm in the
mainline? as my module is really not yet ready for inclusion.
Thanks in advance for your response,
Eric
On Thu, Apr 30, 2009 at 12:32:04PM +0200, Eric Lacombe wrote:
> Hi,
>
> Within a module I work on, I need to access to init_mm, but as it is marked
> UNUSED, I wonder if there is another way (an API) to access to it.
> Otherwise, what can I do to have this mark removed from init_mm in the
> mainline? as my module is really not yet ready for inclusion.
>
> Thanks in advance for your response,
>
It looks to be that it was removed already, somewhat behind schedule, in
commit 9470565579f29486f4ed0ffa50774268b64994b0 after an initial attempt
was made in commit 3abf024d2abb79614d8c4cb25a70d5596f77d0ad. I don't know
if there is a procedure for bringing it back but I would guess it's a call
for the x86 maintainers. I imagine they will want to at least know;
1. Why do you need init_mm exported?
2. Is there an alternative approach to using init_mm?
3. Assuming yes, what are the downsides?
4. When do you think the module will be ready for posting? i.e. is this
really something destined for mainline or some perma-out-of-tree?
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
* Mel Gorman <[email protected]> wrote:
> On Thu, Apr 30, 2009 at 12:32:04PM +0200, Eric Lacombe wrote:
> > Hi,
> >
> > Within a module I work on, I need to access to init_mm, but as it is marked
> > UNUSED, I wonder if there is another way (an API) to access to it.
> > Otherwise, what can I do to have this mark removed from init_mm in the
> > mainline? as my module is really not yet ready for inclusion.
> >
> > Thanks in advance for your response,
> >
>
> It looks to be that it was removed already, somewhat behind schedule, in
> commit 9470565579f29486f4ed0ffa50774268b64994b0 after an initial attempt
> was made in commit 3abf024d2abb79614d8c4cb25a70d5596f77d0ad. I don't know
> if there is a procedure for bringing it back but I would guess it's a call
> for the x86 maintainers. I imagine they will want to at least know;
>
> 1. Why do you need init_mm exported?
> 2. Is there an alternative approach to using init_mm?
> 3. Assuming yes, what are the downsides?
> 4. When do you think the module will be ready for posting? i.e. is this
> really something destined for mainline or some perma-out-of-tree?
yes, those questions have to be answered.
Ingo
On Thu, Apr 30, 2009, Ingo Molnar wrote :
> * Mel Gorman <[email protected]> wrote:
> > On Thu, Apr 30, 2009 at 12:32:04PM +0200, Eric Lacombe wrote:
> > > Hi,
> > >
> > > Within a module I work on, I need to access to init_mm, but as it is
> > > marked UNUSED, I wonder if there is another way (an API) to access to
> > > it. Otherwise, what can I do to have this mark removed from init_mm in
> > > the mainline? as my module is really not yet ready for inclusion.
> > >
> > > Thanks in advance for your response,
> >
> > It looks to be that it was removed already, somewhat behind schedule, in
> > commit 9470565579f29486f4ed0ffa50774268b64994b0 after an initial attempt
> > was made in commit 3abf024d2abb79614d8c4cb25a70d5596f77d0ad. I don't
> > know if there is a procedure for bringing it back but I would guess it's
> > a call for the x86 maintainers. I imagine they will want to at least
> > know;
> >
> > 1. Why do you need init_mm exported?
In brief, my module use hardware virtualization technologies (only Intel ones
for the moment) in order to prevent the kernel from behaving maliciously
(because of a kernel malware) and to prevent the installation of many kernel
malwares. One of my approaches is to preserve some kernel-constrained objects:
for instance, some simple objects like idtr, gdtr, ... or some more
complicated objects like the kernel address space layout, ...
For the latter I use init_mm.pgd.
I wrote a paper and will talk about it at the EICAR conference (May 11th and
12th) this year (http://www.eicar.org/conference/index.htm).
> > 2. Is there an alternative approach to using init_mm?
I don't really take the time to think about another approach, but it seems
natural to access to init_mm.pgd. Maybe, I could access to it by other means,
but that would certainly be ugly :/
> > 3. Assuming yes, what are the downsides?
ugliness ;) maybe kernel version dependent.
> > 4. When do you think the module will be ready for posting? i.e. is this
> > really something destined for mainline or some perma-out-of-tree?
It is destined for mainline as far as I'm concerned. But it needs to be
accepted by the kernel community when it will be ready.
(I work for a french public laboratory, so it will be GPL 2 or 3 licensed
anyway)
>
> yes, those questions have to be answered.
I hope to have adequately answered to your questions.
Best regards,
Eric