All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: Mike Christie <michaelc@cs.wisc.edu>, Neil Brown <neilb@suse.de>,
	Chase Venters <chase.venters@clientec.com>,
	linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
	akpm@osdl.org, a.titov@host.bg, askernel2615@dsgml.com,
	jamie@audible.transient.net
Subject: Re: More information on scsi_cmd_cache leak... (bisect)
Date: Fri, 27 Jan 2006 20:29:46 +0100	[thread overview]
Message-ID: <20060127192946.GF6928@suse.de> (raw)
In-Reply-To: <1138389616.3293.13.camel@mulgrave>

On Fri, Jan 27 2006, James Bottomley wrote:
> On Fri, 2006-01-27 at 13:06 -0600, Mike Christie wrote:
> > It does not have anything to do with this in scsi_io_completion does it?
> > 
> >          if (blk_complete_barrier_rq(q, req, good_bytes >> 9))
> >                  return;
> > 
> > For that case the scsi_cmnd does not get freed. Does it come back around 
> > again and get released from a different path?
> 
> It looks such a likely candidate, doesn't it.  Unfortunately, Tejun Heo
> removed that code around 6 Jan (in [BLOCK] update SCSI to use new
> blk_ordered for barriers), so if it is that, then the latest kernels
> should now not be leaking.

Ah I thought so, seems my memory wasn't totally shot (don't have the
sources with me).

> However, all the avaliable evidence does seem to point to the write
> barrier enforcement.  I'll take another look over those code paths.

The fact that it only happens with raid is very odd, though.

-- 
Jens Axboe


  reply	other threads:[~2006-01-27 19:29 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-27 10:09 More information on scsi_cmd_cache leak... (bisect) Chase Venters
2006-01-27 11:11 ` Neil Brown
2006-01-27 11:23   ` Jens Axboe
2006-01-27 11:28     ` Jens Axboe
2006-01-27 15:20       ` Chase Venters
2006-01-27 19:06       ` Mike Christie
2006-01-27 19:16         ` Jens Axboe
2006-01-27 19:20         ` James Bottomley
2006-01-27 19:29           ` Jens Axboe [this message]
2006-01-27 19:46           ` Mike Christie
2006-01-27 19:49             ` Jens Axboe
2006-01-27 19:53               ` Chase Venters
2006-01-27 20:00                 ` Jens Axboe
2006-01-27 20:02                 ` askernel2615
2006-01-27 20:06                   ` Jens Axboe
2006-01-27 22:50                     ` Tim Morley
2006-01-27 13:33 ` Alexey Dobriyan
2006-01-27 18:41 ` Ariel
2006-01-27 18:58   ` Chase Venters
2006-01-27 21:07   ` Neil Brown
2006-01-27 18:53 ` Ariel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060127192946.GF6928@suse.de \
    --to=axboe@suse.de \
    --cc=James.Bottomley@SteelEye.com \
    --cc=a.titov@host.bg \
    --cc=akpm@osdl.org \
    --cc=askernel2615@dsgml.com \
    --cc=chase.venters@clientec.com \
    --cc=jamie@audible.transient.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=michaelc@cs.wisc.edu \
    --cc=neilb@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.