From patchwork Tue Apr 17 03:46:20 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "jianchao.wang" X-Patchwork-Id: 10344287 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 5F28C6039A for ; Tue, 17 Apr 2018 03:46:13 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 539F928980 for ; Tue, 17 Apr 2018 03:46:13 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 47F2628986; Tue, 17 Apr 2018 03:46:13 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D6BB828980 for ; Tue, 17 Apr 2018 03:46:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751270AbeDQDqL (ORCPT ); Mon, 16 Apr 2018 23:46:11 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:50022 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751210AbeDQDqK (ORCPT ); Mon, 16 Apr 2018 23:46:10 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w3H3foqO043164; Tue, 17 Apr 2018 03:45:42 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id; s=corp-2017-10-26; bh=kJ9p7fEtqIERNgoRZg1mLgCF+19RykOOKvwgZCfd7IE=; b=roYdqRSzRolDbhmJ2a4w4uo6bH7338cBDE3K8RXTWcK/CV7zebJixF58cteHCeemKTW2 EgIZVS1MriPtFuuSlsDAzvHoMI8QlQ0e1pGKDcxLK2zbu7b3lNqOi0OYFe7Eb9STLoJU +ansisUaRxY6ydr9VhoEXwCLukiZZtakU4H/PSRm5Bgv6LTG20FHm8AiLhb+UqarEFFS d+OUZ6HwfetCRCaSiTARPFNGMQHJMOutrJisHQz+d8iGQxjcMJiBdu2mN8hUvIRWDLrz KkO3YyRq5DFgCTZ+4zyQ4hZteugtVshBb+EJBnKjdkkdJRpUaFLR7GrBz6Tzs/54xrdj NA== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2120.oracle.com with ESMTP id 2hbam57uqa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 17 Apr 2018 03:45:42 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w3H3jglx031496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 17 Apr 2018 03:45:42 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w3H3jf0L003290; Tue, 17 Apr 2018 03:45:41 GMT Received: from will-ThinkCentre-M910s.cn.oracle.com (/10.182.69.123) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 16 Apr 2018 20:45:40 -0700 From: Jianchao Wang To: axboe@kernel.dk Cc: bart.vanassche@wdc.com, tj@kernel.org, ming.lei@redhat.com, Martin@Lichtvoll.de, stable@vger.kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] blk-mq: start request gstate with gen 1 Date: Tue, 17 Apr 2018 11:46:20 +0800 Message-Id: <1523936780-1589-1-git-send-email-jianchao.w.wang@oracle.com> X-Mailer: git-send-email 2.7.4 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8865 signatures=668698 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=962 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804170033 Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP rq->gstate and rq->aborted_gstate both are zero before rqs are allocated. If we have a small timeout, when the timer fires, there could be rqs that are never allocated, and also there could be rq that has been allocated but not initialized and started. At the moment, the rq->gstate and rq->aborted_gstate both are 0, thus the blk_mq_terminate_expired will identify the rq is timed out and invoke .timeout early. For scsi, this will cause scsi_times_out to be invoked before the scsi_cmnd is not initialized, scsi_cmnd->device is still NULL at the moment, then we will get crash. Cc: Bart Van Assche Cc: Tejun Heo Cc: Ming Lei Cc: Martin Steigerwald Cc: stable@vger.kernel.org Signed-off-by: Jianchao Wang Reviewed-by: Ming Lei --- block/blk-core.c | 4 ++++ block/blk-mq.c | 7 +++++++ 2 files changed, 11 insertions(+) diff --git a/block/blk-core.c b/block/blk-core.c index abcb868..ce62681 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -201,6 +201,10 @@ void blk_rq_init(struct request_queue *q, struct request *rq) rq->part = NULL; seqcount_init(&rq->gstate_seq); u64_stats_init(&rq->aborted_gstate_sync); + /* + * See comment of blk_mq_init_request + */ + WRITE_ONCE(rq->gstate, MQ_RQ_GEN_INC); } EXPORT_SYMBOL(blk_rq_init); diff --git a/block/blk-mq.c b/block/blk-mq.c index f5c7dbc..d62030a 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -2069,6 +2069,13 @@ static int blk_mq_init_request(struct blk_mq_tag_set *set, struct request *rq, seqcount_init(&rq->gstate_seq); u64_stats_init(&rq->aborted_gstate_sync); + /* + * start gstate with gen 1 instead of 0, otherwise it will be equal + * to aborted_gstate, and be identified timed out by + * blk_mq_terminate_expired. + */ + WRITE_ONCE(rq->gstate, MQ_RQ_GEN_INC); + return 0; }