From patchwork Sat Jul 20 04:56:02 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Nicholas A. Bellinger" X-Patchwork-Id: 260402 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id AB4A52C009E for ; Sat, 20 Jul 2013 14:50:39 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751139Ab3GTEui (ORCPT ); Sat, 20 Jul 2013 00:50:38 -0400 Received: from mail.linux-iscsi.org ([67.23.28.174]:55731 "EHLO linux-iscsi.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750956Ab3GTEuh (ORCPT ); Sat, 20 Jul 2013 00:50:37 -0400 Received: from [192.168.1.68] (75-37-193-228.lightspeed.lsatca.sbcglobal.net [75.37.193.228]) (using SSLv3 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nab) by linux-iscsi.org (Postfix) with ESMTPSA id 1202E22D9D1; Sat, 20 Jul 2013 04:35:52 +0000 (UTC) Message-ID: <1374296162.7397.1098.camel@haakon3.risingtidesystems.com> Subject: Re: [PATCH RESEND 0/1] AHCI: Optimize interrupt processing From: "Nicholas A. Bellinger" To: James Bottomley Cc: Jens Axboe , Mike Christie , Alexander Gordeev , Tejun Heo , linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org, Jeff Garzik , linux-scsi Date: Fri, 19 Jul 2013 21:56:02 -0700 In-Reply-To: <1374267684.7397.1058.camel@haakon3.risingtidesystems.com> References: <20130711102630.GA11133@dhcp-26-207.brq.redhat.com> <1373583637.7397.370.camel@haakon3.risingtidesystems.com> <20130712074559.GA8727@dhcp-26-207.brq.redhat.com> <1373692812.7397.625.camel@haakon3.risingtidesystems.com> <20130716183207.GA6402@dhcp-26-207.brq.redhat.com> <1374010683.7397.880.camel@haakon3.risingtidesystems.com> <20130717161909.GB21468@dhcp-26-207.brq.redhat.com> <1374173515.7397.948.camel@haakon3.risingtidesystems.com> <51E83E32.9050306@cs.wisc.edu> <1374193399.7397.973.camel@haakon3.risingtidesystems.com> <20130719003034.GG28005@kernel.dk> <1374195825.7397.997.camel@haakon3.risingtidesystems.com> <1374215660.7397.1041.camel@haakon3.risingtidesystems.com> <1374248000.2266.20.camel@dabdike> <1374267684.7397.1058.camel@haakon3.risingtidesystems.com> X-Mailer: Evolution 3.4.4-1 Mime-Version: 1.0 Sender: linux-ide-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ide@vger.kernel.org On Fri, 2013-07-19 at 14:01 -0700, Nicholas A. Bellinger wrote: > On Fri, 2013-07-19 at 08:33 -0700, James Bottomley wrote: > > On Thu, 2013-07-18 at 23:34 -0700, Nicholas A. Bellinger wrote: > > > diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c > > > index 0101af5..191bc15 100644 > > > --- a/drivers/ata/libata-scsi.c > > > +++ b/drivers/ata/libata-scsi.c > > > @@ -1144,7 +1144,11 @@ static int ata_scsi_dev_config(struct scsi_device *sdev, > > > "sector_size=%u > PAGE_SIZE, PIO may malfunction\n", > > > sdev->sector_size); > > > > > > - blk_queue_update_dma_alignment(q, sdev->sector_size - 1); > > > + if (!q->mq_ops) { > > > + blk_queue_update_dma_alignment(q, sdev->sector_size - 1); > > > + } else { > > > + printk("Skipping dma_alignment for libata w/ scsi-mq\n"); > > > + } > > > > Amazingly enough there is a reason for the dma alignment, and it wasn't > > just to annoy you, so you can't blindly do this. > > > > The email thread is probably lost in the mists of time, but if I > > remember correctly the problem is that some ahci DMA controllers barf if > > the sector they're doing DMA on crosses a page boundary. Some are > > annoying enough to actually cause silent data corruption. You won't > > find every ahci DMA controller doing this, so the change will work for > > some, but it will be hard to identify those it won't work for until > > people start losing data. > > Thanks for the extra background. > > So at least from what I gather thus far this shouldn't be an issue for > initial testing with scsi-mq <-> libata w/ ata_piix. > > > > > The correct fix, obviously, is to do the bio copy on the kernel path for > > unaligned data. It is OK to assume that REQ_TYPE_FS data is correctly > > aligned (because of the block to page alignment). > > > > Indeed. Looking into the bio_copy_kern() breakage next.. > OK, after further investigation the root cause is a actually a missing bio->bio_end_io() -> bio_copy_kern_endio() -> bio_put() from the blk_end_sync_rq() callback path that scsi-mq REQ_TYPE_BLOCK_PC is currently using. Including the following patch into the scsi-mq working branch now, and reverting the libata dma_alignment=0x03 hack. Alexander, care to give this a try..? --nab --- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/block/blk-exec.c b/block/blk-exec.c index 0761c89..70303d2 100644 --- a/block/blk-exec.c +++ b/block/blk-exec.c @@ -25,7 +25,10 @@ static void blk_end_sync_rq(struct request *rq, int error) struct completion *waiting = rq->end_io_data; rq->end_io_data = NULL; - if (!rq->q->mq_ops) { + if (rq->q->mq_ops) { + if (rq->bio) + bio_endio(rq->bio, error); + } else { __blk_put_request(rq->q, rq); }