From patchwork Tue Apr 5 17:44:06 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ming Lei X-Patchwork-Id: 8753991 Return-Path: X-Original-To: patchwork-linux-block@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id BCBE1C0553 for ; Tue, 5 Apr 2016 17:44:18 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id BF1442038E for ; Tue, 5 Apr 2016 17:44:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7FD2B20364 for ; Tue, 5 Apr 2016 17:44:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758915AbcDERoP (ORCPT ); Tue, 5 Apr 2016 13:44:15 -0400 Received: from mail-pa0-f66.google.com ([209.85.220.66]:33553 "EHLO mail-pa0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758299AbcDERoO (ORCPT ); Tue, 5 Apr 2016 13:44:14 -0400 Received: by mail-pa0-f66.google.com with SMTP id q6so1822825pav.0; Tue, 05 Apr 2016 10:44:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=QHpYa1lSM7UYmomjXcVfHbOLGGrv6MVx9E5Rj7P9tHc=; b=R4SAw9xx4PCQiNKXIZiXVmUpEoEJPDowhnsrcqaqOq1cAdODWkvu/imRqXtUWG9q6m OW5TrI46r5chFqcjb6+KZZ4aeWODulAv0AZaxblSAybIaUMjsyJ/0M6xCY+3lotAdoZe OES5RLQ5OCSTsNSvu1xpzhl9nqu20qQ/QUYKy1l2fbd0LS1YBngLPmHe6Hy3O4degQDT gAyYHqY0Rl1ZjGHGrNpgVLWbHyfhYnkVlECInDsisaHZY+CClppRrcwiSlnATfonzkiO NyNecD7sdIL7k5MC17jrVbOFH1em/ACQYFLiRSxcEvhfP6Ft9CjQVse9r1I+3epYRDoz x/tg== X-Gm-Message-State: AD7BkJLp87/aqNrH3r+PzP3SURCNr5LYx/o2ozclA/9QvxCTJ/X85QPfMPuSvTH7sQtEJw== X-Received: by 10.66.225.235 with SMTP id rn11mr31508767pac.138.1459878253463; Tue, 05 Apr 2016 10:44:13 -0700 (PDT) Received: from localhost (45-125-195-13.ip4.readyserver.sg. [45.125.195.13]) by smtp.gmail.com with ESMTPSA id o71sm48329396pfj.68.2016.04.05.10.44.12 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Tue, 05 Apr 2016 10:44:12 -0700 (PDT) From: Ming Lei To: Jens Axboe , linux-kernel@vger.kernel.org Cc: linux-block@vger.kernel.org, kent.overstreet@gmail.com, Christoph Hellwig , Eric Wheeler , Sebastian Roesner , Ming Lei , stable@vger.kernel.org (4.2+), Shaohua Li Subject: [PATCH] block: make sure big bio is splitted into at most 256 bvecs Date: Wed, 6 Apr 2016 01:44:06 +0800 Message-Id: <1459878246-9249-1-git-send-email-ming.lei@canonical.com> X-Mailer: git-send-email 1.9.1 Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RCVD_IN_SBL, 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 After arbitrary bio size is supported, the incoming bio may be very big. We have to split the bio into small bios so that each holds at most BIO_MAX_PAGES bvecs for safety reason, such as bio_clone(). This patch fixes the following kernel crash: > [ 172.660142] BUG: unable to handle kernel NULL pointer dereference at > 0000000000000028 > [ 172.660229] IP: [] bio_trim+0xf/0x2a > [ 172.660289] PGD 7faf3e067 PUD 7f9279067 PMD 0 > [ 172.660399] Oops: 0000 [#1] SMP > [...] > [ 172.664780] Call Trace: > [ 172.664813] [] ? raid1_make_request+0x2e8/0xad7 [raid1] > [ 172.664846] [] ? blk_queue_split+0x377/0x3d4 > [ 172.664880] [] ? md_make_request+0xf6/0x1e9 [md_mod] > [ 172.664912] [] ? generic_make_request+0xb5/0x155 > [ 172.664947] [] ? prio_io+0x85/0x95 [bcache] > [ 172.664981] [] ? register_cache_set+0x355/0x8d0 [bcache] > [ 172.665016] [] ? register_bcache+0x1006/0x1174 [bcache] Fixes: 54efd50(block: make generic_make_request handle arbitrarily sized bios) Reported-by: Sebastian Roesner Reported-by: Eric Wheeler Cc: stable@vger.kernel.org (4.2+) Cc: Shaohua Li Signed-off-by: Ming Lei --- I can reproduce the issue and verify the fix by the following approach: - create one raid1 over two virtio-blk - build bcache device over the above raid1 and another cache device. - set cache mode as writeback - run random write over ext4 on the bcache device - then the crash can be triggered block/blk-merge.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/block/blk-merge.c b/block/blk-merge.c index 2613531..9a8651f 100644 --- a/block/blk-merge.c +++ b/block/blk-merge.c @@ -79,6 +79,18 @@ static inline unsigned get_max_io_size(struct request_queue *q, /* aligned to logical block size */ sectors &= ~(mask >> 9); + /* + * With arbitrary bio size, the incoming bio may be very big. + * We have to split the bio into small bios so that each holds + * at most BIO_MAX_PAGES bvecs for safety reason, such as + * bio_clone(). + * + * In the future, the limit might be converted into per-queue + * flag. + */ + sectors = min_t(unsigned, sectors, BIO_MAX_PAGES << + (PAGE_CACHE_SHIFT - 9)); + return sectors; }