From patchwork Fri Jul 28 19:41:18 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Valente X-Patchwork-Id: 9869323 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 B3A2460382 for ; Fri, 28 Jul 2017 19:41:51 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B10D128876 for ; Fri, 28 Jul 2017 19:41:51 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id A5C2D2887A; Fri, 28 Jul 2017 19:41:51 +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=-7.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_HI 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 20B9828876 for ; Fri, 28 Jul 2017 19:41:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752712AbdG1Tlu (ORCPT ); Fri, 28 Jul 2017 15:41:50 -0400 Received: from mail-wr0-f178.google.com ([209.85.128.178]:37313 "EHLO mail-wr0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752505AbdG1Tlt (ORCPT ); Fri, 28 Jul 2017 15:41:49 -0400 Received: by mail-wr0-f178.google.com with SMTP id 33so102061196wrz.4 for ; Fri, 28 Jul 2017 12:41:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=xGPvalquzxVvUhzB9xHS8EkSO6lzEnJIgfZjTxf0OvU=; b=f/AG9NqXbY0VjMxdDQxpYnYgwU5wV0Wuxcpi7lfAOJ18i1iogy5M5H3u07G3n78zXT 6x0Ba8bZNAvkLFiRy4FJIm8bjuO36652xVhmsFHXDArgsaaN2uo8PO9VLbBwtgLvnWTO sL/VeX9PG55Nycp4F1iy4EIW29+G15sKyTTEE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=xGPvalquzxVvUhzB9xHS8EkSO6lzEnJIgfZjTxf0OvU=; b=tRacnUzrGCYWO1SLuYgNol/jo8W8Kv56VoSDWzYG/S5kW5HxRx/iWB2BRHChWpm4La ZyJhbR0azBVot8+rWDh2I07cDEY8t1jpiPEWWT2HNfj+sGeAPs2jO2N3THT/shQwQEdF uDHMJzCDhVmxYUd5YXwluTmZBPinbKZCygB7ilNFD5QqR7+Bkq2OeRPON2D57ZAhEhdi Zi2FEnyo+nTF/VVk9XKBUBThhPXMMg39/DVJHEnf0UmGmXvLTfBzzfVPdq1NwsV1yS9P mCjpM+Pxz/uusClee7Td/4UB1ygol13ebSawZxu+lIU6Oo3o1DaQ0MIeImTmBTYE2CxH AvYg== X-Gm-Message-State: AIVw110BX36g8y/wE2iQruHQsxLZKYPLwTMK03kvyrjZNwkvbIst8Qda 8UyKodl8+cg09qRhE3fP7w== X-Received: by 10.223.154.7 with SMTP id z7mr6596638wrb.136.1501270908290; Fri, 28 Jul 2017 12:41:48 -0700 (PDT) Received: from localhost.localdomain ([185.14.11.247]) by smtp.gmail.com with ESMTPSA id 77sm5071797wmk.8.2017.07.28.12.41.46 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 28 Jul 2017 12:41:47 -0700 (PDT) From: Paolo Valente To: Jens Axboe Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, ulf.hansson@linaro.org, broonie@kernel.org, lnicola@dend.ro, Paolo Valente Subject: [PATCH BUGFIX] block, bfq: reset in_service_entity if it becomes idle Date: Fri, 28 Jul 2017 21:41:18 +0200 Message-Id: <20170728194118.8249-1-paolo.valente@linaro.org> X-Mailer: git-send-email 2.10.0 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 BFQ implements hierarchical scheduling by representing each group of queues with a generic parent entity. For each parent entity, BFQ maintains an in_service_entity pointer: if one of the child entities happens to be in service, in_service_entity points to it. The resetting of these pointers happens only on queue expirations: when the in-service queue is expired, i.e., stops to be the queue in service, BFQ resets all in_service_entity pointers along the parent-entity path from this queue to the root entity. Functions handling the scheduling of entities assume, naturally, that in-service entities are active, i.e., have pending I/O requests (or, as a special case, even if they have no pending requests, they are expected to receive a new request very soon, with the scheduler idling the storage device while waiting for such an event). Unfortunately, the above resetting scheme of the in_service_entity pointers may cause this assumption to be violated. For example, the in-service queue may happen to remain without requests because of a request merge. In this case the queue does become idle, and all related data structures are updated accordingly. But in_service_entity still points to the queue in the parent entity. This inconsistency may even propagate to higher-level parent entities, if they happen to become idle as well, as a consequence of the leaf queue becoming idle. For this queue and parent entities, scheduling functions have an undefined behaviour, and, as reported, may easily lead to kernel crashes or hangs. This commit addresses this issue by simply resetting the in_service_entity field also when it is detected to point to an entity becoming idle (regardless of why the entity becomes idle). Reported-by: Laurentiu Nicola Signed-off-by: Paolo Valente Tested-by: Laurentiu Nicola --- block/bfq-wf2q.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/block/bfq-wf2q.c b/block/bfq-wf2q.c index 979f8f2..881bbe5 100644 --- a/block/bfq-wf2q.c +++ b/block/bfq-wf2q.c @@ -1158,8 +1158,10 @@ bool __bfq_deactivate_entity(struct bfq_entity *entity, bool ins_into_idle_tree) st = bfq_entity_service_tree(entity); is_in_service = entity == sd->in_service_entity; - if (is_in_service) + if (is_in_service) { bfq_calc_finish(entity, entity->service); + sd->in_service_entity = NULL; + } if (entity->tree == &st->active) bfq_active_extract(st, entity);