Messages in this thread |  | | Date | Tue, 29 Nov 2011 15:18:03 -0500 | | From | Mike Snitzer <> | | Subject | Re: [GIT PULL] Queue free fix (was Re: [PATCH] block: Free queue resources at blk_release_queue()) |
| |
On Tue, Nov 29 2011 at 7:00am -0500, Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
> > > > Hmm. Just to be on the safe side, could you try this one: > > > > > > > > diff --git a/drivers/md/dm-mpath.c b/drivers/md/dm-mpath.c > > > > index 5e0090e..e6fad46 100644 > > > > --- a/drivers/md/dm-mpath.c > > > > +++ b/drivers/md/dm-mpath.c > > > > @@ -920,8 +920,10 @@ static int multipath_map(struct dm_target *ti, > > > > struct reque > > > > st *clone, > > > > map_context->ptr = mpio; > > > > clone->cmd_flags |= REQ_FAILFAST_TRANSPORT; > > > > r = map_io(m, clone, mpio, 0); > > > > - if (r < 0 || r == DM_MAPIO_REQUEUE) > > > > + if (r < 0 || r == DM_MAPIO_REQUEUE) { > > > > mempool_free(mpio, m->mpio_pool); > > > > + map_context->ptr = NULL; > > > > + } > > > > > > > > return r; > > > > } > > > > > > With your patch we haven't been able to reproduce the kernel crash until now. > > > Now we "only" run into I/O stalls, which before your patch we also did. But > > > repeatedly rebooting and retrying and ignoring the I/O stalls always lead to > > > a crash. > > > Gonzalo will run a couple of extra rounds so we can have a feeling if at least > > > one of the bugs could be fixed with your patch ;) > > > > Hi, > > > > Any update after further testing with Hannes' patch? > > Sorry for the late update, our internal IBM IMAP servers have been down > for nearly a week :/ > > So, we were unable to reproduce the original bug with the patch applied > during various runs.
OK, so it seems to be a benenficial change (and obviously correct to me). Hannes, care to formally post your fix to dm-devel so we can get it in 3.2-rc?
> However, we ran into this one instead, which is yet another use-after-free bug > (I need to double check, but I'm quite sure that a freed struct scsi_cmnd > caused this).
OK, yeah something is causing poisoned (POISON_FREE) memory to be used.
> [ 4906.683654] Unable to handle kernel pointer dereference at virtual kernel address 6b6b6b6b6b6b6000
...
> Gonzalo also tried 2.6.38.8 as suggested and ran into this one: > > [ 292.877936] ------------[ cut here ]------------ > [ 292.877939] Kernel BUG at 6b6b6b6b6b6b6b6d [verbose debug info unavailable]
Again, more poison.
Seems this test is causing us to fall on our face no matter what. Likely, best to leave this 2.6.38 blk_unplug crash to one side and continue focusing on latest upstream.
Mike
|  |