From: Jens Axboe <axboe@suse.de>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: "Pasi Kärkkäinen" <pasik@iki.fi>, Nix <nix@esperi.org.uk>,
Ariel <askernel2615@dsgml.com>,
"Jamie Heilman" <jamie@audible.transient.net>,
"Chase Venters" <chase.venters@clientec.com>,
"Arjan van de Ven" <arjan@infradead.org>,
linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-scsi@vger.kernel.org
Subject: Re: memory leak in scsi_cmd_cache 2.6.15
Date: Sun, 29 Jan 2006 20:57:33 +0100 [thread overview]
Message-ID: <20060129195733.GH13831@suse.de> (raw)
In-Reply-To: <1138552692.3352.6.camel@mulgrave>
On Sun, Jan 29 2006, James Bottomley wrote:
> On Sun, 2006-01-29 at 17:50 +0200, Pasi Kärkkäinen wrote:
> > Are all sata drivers affected by this bug in 2.6.15?
>
> Well, all SCSI drivers are affected by it, yes. However, SATA devices
> are peculiarly affected because the ordered_flush method of enforcing
> barriers, which is where the leak is, can only be implemented for
> devices that don't do tag command queueing (i.e. don't have multiple
> commands outstanding for a given single device). By and large, SATA
> drivers are the only drivers in the SCSI subsystem that can't do tag
> command queueing, which is why the problem didn't show up for any other
> type of SCSI driver.
2.6.15 didn't support barriers for anything other than ordered flush
SCSI low level drivers, hence only SATA is affected.
> > Any 'official' patch available?
>
> Well, yes, 2.6.16-rc1 has this fixed. I can't see backporting this to
> 2.6.15.x since it represents a significant functionality enhancement as
> well, so I'd lean towards just forcing ordered_flush to zero in 2.6.15.x
> which seems to be the best bug fix.
Agree, backporting the barrier rewrite would be insane for stable.
> > Or is the recommended workaround to set ordered_flush to 0 to fix this..
> > does that have any downsides?
>
> setting ordered_flush to zero for 2.6.15 turns off the flushing
> functionality and restores the old behaviour. I don't see that there
> would be any down side to this.
Just the usual correctness issue, but since it's leaky it doesn't seem
like a big deal to wait for 2.6.16.
So here's a patch for 2.6.15:
---
Turn off ordered flush barriers for SCSI driver, since the SCSI barrier
code has a command leak.
Signed-off-by: Jens Axboe <axboe@suse.de>
--- linux-2.6.15.1/drivers/scsi/scsi_lib.c~ 2006-01-29 11:55:08.000000000 -0800
+++ linux-2.6.15.1/drivers/scsi/scsi_lib.c 2006-01-29 11:55:38.000000000 -0800
@@ -1534,11 +1534,6 @@
*/
if (shost->ordered_tag)
blk_queue_ordered(q, QUEUE_ORDERED_TAG);
- else if (shost->ordered_flush) {
- blk_queue_ordered(q, QUEUE_ORDERED_FLUSH);
- q->prepare_flush_fn = scsi_prepare_flush_fn;
- q->end_flush_fn = scsi_end_flush_fn;
- }
if (!shost->use_clustering)
clear_bit(QUEUE_FLAG_CLUSTER, &q->queue_flags);
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Jens Axboe <axboe@suse.de>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: "Pasi Kärkkäinen" <pasik@iki.fi>, Nix <nix@esperi.org.uk>,
Ariel <askernel2615@dsgml.com>,
"Jamie Heilman" <jamie@audible.transient.net>,
"Chase Venters" <chase.venters@clientec.com>,
"Arjan van de Ven" <arjan@infradead.org>,
linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-scsi@vger.kernel.org
Subject: Re: memory leak in scsi_cmd_cache 2.6.15
Date: Sun, 29 Jan 2006 20:57:33 +0100 [thread overview]
Message-ID: <20060129195733.GH13831@suse.de> (raw)
In-Reply-To: <1138552692.3352.6.camel@mulgrave>
On Sun, Jan 29 2006, James Bottomley wrote:
> On Sun, 2006-01-29 at 17:50 +0200, Pasi Kärkkäinen wrote:
> > Are all sata drivers affected by this bug in 2.6.15?
>
> Well, all SCSI drivers are affected by it, yes. However, SATA devices
> are peculiarly affected because the ordered_flush method of enforcing
> barriers, which is where the leak is, can only be implemented for
> devices that don't do tag command queueing (i.e. don't have multiple
> commands outstanding for a given single device). By and large, SATA
> drivers are the only drivers in the SCSI subsystem that can't do tag
> command queueing, which is why the problem didn't show up for any other
> type of SCSI driver.
2.6.15 didn't support barriers for anything other than ordered flush
SCSI low level drivers, hence only SATA is affected.
> > Any 'official' patch available?
>
> Well, yes, 2.6.16-rc1 has this fixed. I can't see backporting this to
> 2.6.15.x since it represents a significant functionality enhancement as
> well, so I'd lean towards just forcing ordered_flush to zero in 2.6.15.x
> which seems to be the best bug fix.
Agree, backporting the barrier rewrite would be insane for stable.
> > Or is the recommended workaround to set ordered_flush to 0 to fix this..
> > does that have any downsides?
>
> setting ordered_flush to zero for 2.6.15 turns off the flushing
> functionality and restores the old behaviour. I don't see that there
> would be any down side to this.
Just the usual correctness issue, but since it's leaky it doesn't seem
like a big deal to wait for 2.6.16.
So here's a patch for 2.6.15:
---
Turn off ordered flush barriers for SCSI driver, since the SCSI barrier
code has a command leak.
Signed-off-by: Jens Axboe <axboe@suse.de>
--- linux-2.6.15.1/drivers/scsi/scsi_lib.c~ 2006-01-29 11:55:08.000000000 -0800
+++ linux-2.6.15.1/drivers/scsi/scsi_lib.c 2006-01-29 11:55:38.000000000 -0800
@@ -1534,11 +1534,6 @@
*/
if (shost->ordered_tag)
blk_queue_ordered(q, QUEUE_ORDERED_TAG);
- else if (shost->ordered_flush) {
- blk_queue_ordered(q, QUEUE_ORDERED_FLUSH);
- q->prepare_flush_fn = scsi_prepare_flush_fn;
- q->end_flush_fn = scsi_end_flush_fn;
- }
if (!shost->use_clustering)
clear_bit(QUEUE_FLAG_CLUSTER, &q->queue_flags);
--
Jens Axboe
next prev parent reply other threads:[~2006-01-29 19:57 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-22 2:13 memory leak in scsi_cmd_cache 2.6.15 Ariel
2006-01-22 6:58 ` Andrew Morton
2006-01-22 18:18 ` Ariel
2006-01-22 8:16 ` Arjan van de Ven
2006-01-22 8:20 ` Arjan van de Ven
2006-01-22 18:51 ` Ariel
2006-01-22 19:07 ` Arjan van de Ven
2006-01-22 19:16 ` Chase Venters
2006-01-22 19:24 ` Arjan van de Ven
2006-01-22 19:46 ` Chase Venters
2006-01-23 2:19 ` Ariel
2006-01-22 19:24 ` Chase Venters
2006-01-23 0:58 ` Jamie Heilman
2006-01-23 2:14 ` Ariel
2006-01-23 6:18 ` Arjan van de Ven
2006-01-23 6:28 ` Chase Venters
2006-01-23 6:46 ` Ariel
2006-01-23 7:25 ` Jamie Heilman
2006-01-23 8:33 ` Jens Axboe
2006-01-27 11:28 ` Jamie Heilman
2006-01-28 19:27 ` Jens Axboe
2006-01-26 18:12 ` Ariel
2006-01-27 16:23 ` Nix
2006-01-28 19:27 ` Jens Axboe
2006-01-28 19:46 ` Chase Venters
2006-01-28 21:29 ` Jens Axboe
2006-01-29 15:50 ` Pasi Kärkkäinen
2006-01-29 16:38 ` James Bottomley
2006-01-29 17:10 ` Pasi Kärkkäinen
2006-01-29 19:57 ` Jens Axboe [this message]
2006-01-29 19:57 ` Jens Axboe
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=20060129195733.GH13831@suse.de \
--to=axboe@suse.de \
--cc=James.Bottomley@SteelEye.com \
--cc=arjan@infradead.org \
--cc=askernel2615@dsgml.com \
--cc=chase.venters@clientec.com \
--cc=jamie@audible.transient.net \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=nix@esperi.org.uk \
--cc=pasik@iki.fi \
/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.