[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200804120106.52981.rusty@rustcorp.com.au>
Date: Sat, 12 Apr 2008 01:06:52 +1000
From: Rusty Russell <rusty@...tcorp.com.au>
To: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
Cc: akpm@...ux-foundation.org, Ingo Molnar <mingo@...e.hu>,
linux-kernel@...r.kernel.org, Andi Kleen <andi@...stfloor.org>,
Adrian Bunk <bunk@...sta.de>,
Alexey Dobriyan <adobriyan@...il.com>,
Christoph Hellwig <hch@...radead.org>, akpm@...l.org
Subject: Re: [patch 16/17] Immediate Values - Documentation
On Friday 11 April 2008 11:16:47 Mathieu Desnoyers wrote:
> * Rusty Russell (rusty@...tcorp.com.au) wrote:
> > On Thursday 10 April 2008 01:08:45 Mathieu Desnoyers wrote:
> > > If you have to read the immediate values from a function declared as
> > > __init or __exit, you should explicitly use _imv_read(), which will
> > > fall back on a global variable read. Failing to do so will leave a
> > > reference to the __init section after it is freed (it would generate a
> > > modpost warning).
> >
> > That's a real usability wart. Couldn't we skip these in the patching
> > loop if required and revert so noone can make this mistake?
>
> Yeah, I know :(
>
> Well, only if we can find a way to detect the macro is put within a init
> or exit section. Is there some assembly trickery that would permit us to
> do that ?
>
> Otherwise, given the memory freed from the init section could be reused
> later by the kernel, I don't see how we can detect the pointer leads to
> a freed init section and, say, a module.
In theory although not in practice, since everyone vmallocs modules. Let's
not rely on that tho.
How about we sweep the immediate table on init discard and remove/mark all the
init and exit references?
Cheers,
Rusty.
--
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/
Powered by blists - more mailing lists