In message <[EMAIL PROTECTED]>, =?utf-8?B?SsO2cm4=?= Engel writes:
[...]
> Patch didn't compile due to function ordering. Here is an updated version.
Joern/Peter, I've tested this updated patch with v2.6.24-rc8-74-ga7da60f.
It worked fine for me.
Thanks,
Erez.
> Acked-and-tested-by: Joern
On Tue, 8 January 2008 11:47:00 +1100, Rusty Russell wrote:
>
> There's nothing wrong with this patch, but I think it papers over a more
> general problem: we enter the module (to parse args) while it's not in the
> module list. This also means we won't get a nice oops if it crashes.
>
>
On Tue, 2008-01-08 at 11:47 +1100, Rusty Russell wrote:
> On Monday 07 January 2008 21:05:26 Peter Zijlstra wrote:
> > On Sun, 2008-01-06 at 14:11 -0500, Erez Zadok wrote:
> > > > Ingo, Peter, does either of you actually care about this problem? In
> > > > the last round when I debugged this
On Tue, 2008-01-08 at 11:47 +1100, Rusty Russell wrote:
On Monday 07 January 2008 21:05:26 Peter Zijlstra wrote:
On Sun, 2008-01-06 at 14:11 -0500, Erez Zadok wrote:
Ingo, Peter, does either of you actually care about this problem? In
the last round when I debugged this problem there
On Tue, 8 January 2008 11:47:00 +1100, Rusty Russell wrote:
There's nothing wrong with this patch, but I think it papers over a more
general problem: we enter the module (to parse args) while it's not in the
module list. This also means we won't get a nice oops if it crashes.
This
On Monday 07 January 2008 21:05:26 Peter Zijlstra wrote:
> On Sun, 2008-01-06 at 14:11 -0500, Erez Zadok wrote:
> > > Ingo, Peter, does either of you actually care about this problem? In
> > > the last round when I debugged this problem there was a notable lack of
> > > reaction from either of
On Mon, 2008-01-07 at 11:20 +0100, Jörn Engel wrote:
> On Mon, 7 January 2008 11:05:26 +0100, Peter Zijlstra wrote:
> >
> > Would something like this work for people?
>
> Looks a lot better than what I thought of. However, does the #ifdef
> within is_module_address() make sense when afaict
On Mon, 7 January 2008 11:05:26 +0100, Peter Zijlstra wrote:
>
> Would something like this work for people?
Looks a lot better than what I thought of. However, does the #ifdef
within is_module_address() make sense when afaict lockdep is the only
caller of that function? Looks as if the whole
On Sun, 2008-01-06 at 14:11 -0500, Erez Zadok wrote:
> > Ingo, Peter, does either of you actually care about this problem? In
> > the last round when I debugged this problem there was a notable lack of
> > reaction from either of you.
>
> The problem appears to be an interaction of two
On Mon, 7 January 2008 11:05:26 +0100, Peter Zijlstra wrote:
Would something like this work for people?
Looks a lot better than what I thought of. However, does the #ifdef
within is_module_address() make sense when afaict lockdep is the only
caller of that function? Looks as if the whole
On Mon, 2008-01-07 at 11:20 +0100, Jörn Engel wrote:
On Mon, 7 January 2008 11:05:26 +0100, Peter Zijlstra wrote:
Would something like this work for people?
Looks a lot better than what I thought of. However, does the #ifdef
within is_module_address() make sense when afaict lockdep is
On Monday 07 January 2008 21:05:26 Peter Zijlstra wrote:
On Sun, 2008-01-06 at 14:11 -0500, Erez Zadok wrote:
Ingo, Peter, does either of you actually care about this problem? In
the last round when I debugged this problem there was a notable lack of
reaction from either of you.
The
On Sun, 6 January 2008 14:11:47 -0500, Erez Zadok wrote:
>
> The problem appears to be an interaction of two components--module loading
> and lockdep--that's perhaps why it wasn't given enough attention.
Correct. For modules lockdep depends on initializations done after
module_init has
In message <[EMAIL PROTECTED]>, =?utf-8?B?SsO2cm4=?= Engel writes:
> Maybe it is not obvious that I maintain this driver and would like to be
> kept on Cc:. Will send a patch to fix that shortly.
I was looking in MAINTAINERS, and you weren't listed on the main MTD section
as a maintainer.
On Sun, 2008-01-06 at 14:13 +0100, Jörn Engel wrote:
> Ingo, Peter, does either of you actually care about this problem? In
> the last round when I debugged this problem there was a notable lack of
> reaction from either of you.
Yeah I do, I just know very little about the module stuff and
Maybe it is not obvious that I maintain this driver and would like to be
kept on Cc:. Will send a patch to fix that shortly.
On Sun, 6 January 2008 02:17:32 -0500, Erez Zadok wrote:
>
> Hi David,
>
> I've reported before a lockdep warning when block2mtd is modloaded, and a
> device is
On Sun, 2008-01-06 at 14:13 +0100, Jörn Engel wrote:
Ingo, Peter, does either of you actually care about this problem? In
the last round when I debugged this problem there was a notable lack of
reaction from either of you.
Yeah I do, I just know very little about the module stuff and
In message [EMAIL PROTECTED], =?utf-8?B?SsO2cm4=?= Engel writes:
Maybe it is not obvious that I maintain this driver and would like to be
kept on Cc:. Will send a patch to fix that shortly.
I was looking in MAINTAINERS, and you weren't listed on the main MTD section
as a maintainer. Perhaps
On Sun, 6 January 2008 14:11:47 -0500, Erez Zadok wrote:
The problem appears to be an interaction of two components--module loading
and lockdep--that's perhaps why it wasn't given enough attention.
Correct. For modules lockdep depends on initializations done after
module_init has finished.
Hi David,
I've reported before a lockdep warning when block2mtd is modloaded, and a
device is initialized, as in
modprobe block2mtd block2mtd=/dev/loop0
A typical warning looks like this:
BUG: key f88565c0 not in .data!
WARNING: at kernel/lockdep.c:2331 lockdep_init_map()
Pid: 1823,
Hi David,
I've reported before a lockdep warning when block2mtd is modloaded, and a
device is initialized, as in
modprobe block2mtd block2mtd=/dev/loop0
A typical warning looks like this:
BUG: key f88565c0 not in .data!
WARNING: at kernel/lockdep.c:2331 lockdep_init_map()
Pid: 1823,
21 matches
Mail list logo
