From patchwork Mon Feb 20 18:45:42 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ilya Dryomov X-Patchwork-Id: 9583483 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 87FFC6047C for ; Mon, 20 Feb 2017 18:53:57 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8332A284F6 for ; Mon, 20 Feb 2017 18:53:57 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 77AFF287EE; Mon, 20 Feb 2017 18:53:57 +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=-6.5 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM 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 26DD1284F6 for ; Mon, 20 Feb 2017 18:53:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750936AbdBTSx4 (ORCPT ); Mon, 20 Feb 2017 13:53:56 -0500 Received: from mail-vk0-f67.google.com ([209.85.213.67]:36248 "EHLO mail-vk0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750868AbdBTSxz (ORCPT ); Mon, 20 Feb 2017 13:53:55 -0500 Received: by mail-vk0-f67.google.com with SMTP id n125so8939418vke.3; Mon, 20 Feb 2017 10:53:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=f1tsIWx77/lloWc1yfdwwHZvBwGyDOp/KPSS8vyuPJM=; b=M5G4Q5BJdBpqCXqMyYvmki/EeCV70XnxcGE/fQSpLZmjiJiaLSLeLod2y0/iw5L1hb BWn+XOLlhYoChcFw2Re1D5RuC8tXdM0od+8yB0vZigNgyf3kj7dqSas1urAwBGYXJbRM p8dRu7OcF8c0xEkjx7EymnIWhdZtq07Om25JiKFFDkVG0x+RlAH5AGNcTXOIEVKOEnEF qGnlclt7/5Rgu2ymSzbWDqnpSLym2ZaWvOGpIS2PE/Mx84hWe2kiE9bMYOgB2QVcYA1I zVykVlO4aLUSsS+mDaE3BvfltLLJjOWDRd05sSQUZiRPOPvJBPFGlV2FgJwevwXOiTRu 2sKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=f1tsIWx77/lloWc1yfdwwHZvBwGyDOp/KPSS8vyuPJM=; b=s04mDhcTUvZhFqOaMlLAqMhiYCAkyvjl3J0MhFieZdz79b8SvI1ca33lsQk927z1Sn MyuaTrvw48P9WGWBoEpO5JJamMzb888KbTH6FP8uS1AUDC/shj0hFDrb1z6UsHFuqTSn 6WqOAIGCdNIHDnOUAliiH/X7piaFXKHwL887cc96MJok7DDkv5klCO/38nw7Q5CYUz1y mORXLaxS95MxXStpBUn8lDwFTSwXfCzS3Hah5784X4q10NdhCiJpLATrIiCQeCCoqiq8 F3CptGvjGRcWvH22dLLwSVyoEUVLaJ2hO98ZhxS/uPl0R2mI/Im3StGCeW+b84nlQtTb 9NYQ== X-Gm-Message-State: AMke39kg/LnhX2QHBj3CoHFt8C/DLxcoY5AFp24GEZd9gckuux/YBjyUQZ7gYldKRCOLpF5XTWP3m5gW1InQpQ== X-Received: by 10.31.6.73 with SMTP id 70mr10510855vkg.173.1487616342513; Mon, 20 Feb 2017 10:45:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.76.194 with HTTP; Mon, 20 Feb 2017 10:45:42 -0800 (PST) From: Ilya Dryomov Date: Mon, 20 Feb 2017 19:45:42 +0100 Message-ID: Subject: blk_integrity_revalidate() clears BDI_CAP_STABLE_WRITES To: "Martin K. Petersen" Cc: Ceph Development , linux-block@vger.kernel.org, Dan Williams , Christoph Hellwig 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 Hello, rbd requires stable pages if ceph message data CRCs are enabled. To that end we set BDI_CAP_STABLE_WRITES in rbd_init_disk(), but since commit 25520d55cdb6 ("block: Inline blk_integrity in struct gendisk", went into 4.4) this bit is almost immediately cleared: add_disk register_disk blkdev_get rescan_partitions blk_integrity_revalidate void blk_integrity_revalidate(struct gendisk *disk) { struct blk_integrity *bi = &disk->queue->integrity; if (!(disk->flags & GENHD_FL_UP)) return; if (bi->profile) disk->queue->backing_dev_info.capabilities |= BDI_CAP_STABLE_WRITES; else disk->queue->backing_dev_info.capabilities &= ~BDI_CAP_STABLE_WRITES; } ceph messenger is responsible for generating/verifying CRCs, so we don't call blk_integrity_register() -- bi->profile is NULL. Martin, could you please explain blk_integrity_revalidate() and its GENHD_FL_UP check in particular? We have the queue, bi->profile can't be NULL after blk_integrity_register(), and since the latter "must" be used for registering the profile with the block layer, wouldn't the following be sufficient for blk_integrity users? @@ -430,26 +430,11 @@ EXPORT_SYMBOL(blk_integrity_register); */ void blk_integrity_unregister(struct gendisk *disk) { - blk_integrity_revalidate(disk); + disk->queue->backing_dev_info.capabilities &= ~BDI_CAP_STABLE_WRITES; memset(&disk->queue->integrity, 0, sizeof(struct blk_integrity)); } EXPORT_SYMBOL(blk_integrity_unregister); blk_integrity_revalidate() can then go away -- I can send the full patch later. The alternative seems to be to set up a bogus blk_integrity_profile (nop_profile won't do -- this one would have to be truly bogus w/ NULL ->*_fn) under BLK_DEV_INTEGRITY ifdefs and hope that nothing breaks. That can't be the right thing to do here... Thanks, Ilya diff --git a/block/blk-integrity.c b/block/blk-integrity.c index d69c5c79f98e..319f2e4f4a8b 100644 --- a/block/blk-integrity.c +++ b/block/blk-integrity.c @@ -417,7 +417,7 @@ void blk_integrity_register(struct gendisk *disk, struct blk_integrity *template bi->tuple_size = template->tuple_size; bi->tag_size = template->tag_size; - blk_integrity_revalidate(disk); + disk->queue->backing_dev_info.capabilities |= BDI_CAP_STABLE_WRITES; } EXPORT_SYMBOL(blk_integrity_register);