From patchwork Thu Oct 15 08:10:04 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sumit Saxena X-Patchwork-Id: 7403751 Return-Path: X-Original-To: patchwork-linux-scsi@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id B67299F1B9 for ; Thu, 15 Oct 2015 08:20:58 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id D7F3820460 for ; Thu, 15 Oct 2015 08:20:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 04E3C20138 for ; Thu, 15 Oct 2015 08:20:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751834AbbJOIUu (ORCPT ); Thu, 15 Oct 2015 04:20:50 -0400 Received: from smtp.avagotech.com ([202.86.248.48]:60964 "EHLO rndsmtp1.avagotech.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751276AbbJOIUm (ORCPT ); Thu, 15 Oct 2015 04:20:42 -0400 X-Greylist: delayed 606 seconds by postgrey-1.27 at vger.kernel.org; Thu, 15 Oct 2015 04:20:41 EDT Received: from casmh001.sjs.avagotech.net (casmh001.sjs.avagotech.net [135.141.8.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rndsmtp1.avagotech.com (Postfix) with ESMTPS id 72214100005; Thu, 15 Oct 2015 01:10:33 -0700 (PDT) Received: from palmhbs0.lsi.com (palmhbs0.lsi.com [128.94.222.181]) by casmh001.sjs.avagotech.net (8.14.4/8.14.4) with ESMTP id t9F8AU4w004831; Thu, 15 Oct 2015 01:10:31 -0700 Received: from localhost (dhcp-135-24-192-102.lsi.com [135.24.192.102]) by palmhbs0.lsi.com (8.13.8/8.12.11) with ESMTP id t9F8HMD6029627; Thu, 15 Oct 2015 04:17:23 -0400 From: sumit.saxena@avagotech.com Message-Id: <201510150817.t9F8HMD6029627@palmhbs0.lsi.com> Date: Thu, 15 Oct 2015 13:40:04 +0530 To: linux-scsi@vger.kernel.org, stable@vger.kernel.org, thenzl@redhat.com, martin.petersen@oracle.com, hch@infradead.org, jbottomley@parallels.com, kashyap.desai@avagotech.com, sumit.saxena@avagotech.com, kiran-kumar.kasturi@avagotech.com Subject: [PATCH 05/12] megaraid_sas : Donot use PAGE_SIZE macro for calculation of max_sectors per IO request Cc: uday.lingala@avagotech.com User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Do not use PAGE_SIZE marco to calculate max_sectors per IO request. Driver code assumes PAGE_SIZE will be always 4096 which can do lead to wrongly calculated value if PAGE_SIZE is not 4096. This issue was reported in Ubuntu Bugzilla Bug #1475166. Cc: Signed-off-by: Sumit Saxena Signed-off-by: Kashyap Desai Reviewed-by: Tomas Henzl --- drivers/scsi/megaraid/megaraid_sas.h | 2 ++ drivers/scsi/megaraid/megaraid_sas_base.c | 2 +- 2 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas.h b/drivers/scsi/megaraid/megaraid_sas.h index d236cc2..fab7602 100644 --- a/drivers/scsi/megaraid/megaraid_sas.h +++ b/drivers/scsi/megaraid/megaraid_sas.h @@ -388,6 +388,8 @@ enum MR_EVT_ARGS { MR_EVT_ARGS_GENERIC, }; + +#define SGE_BUFFER_SIZE 4096 /* * define constants for device list query options */ diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c index 92c5bbe..6204a66 100644 --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -4871,7 +4871,7 @@ static int megasas_init_fw(struct megasas_instance *instance) instance->max_sectors_per_req = instance->max_num_sge * - PAGE_SIZE / 512; + SGE_BUFFER_SIZE / 512; if (tmp_sectors && (instance->max_sectors_per_req > tmp_sectors)) instance->max_sectors_per_req = tmp_sectors;