From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 42AFFC43381 for ; Fri, 29 Mar 2019 14:38:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E68092183F for ; Fri, 29 Mar 2019 14:38:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=kernel-dk.20150623.gappssmtp.com header.i=@kernel-dk.20150623.gappssmtp.com header.b="jdY5yGzw" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729058AbfC2OiI (ORCPT ); Fri, 29 Mar 2019 10:38:08 -0400 Received: from mail-it1-f193.google.com ([209.85.166.193]:53501 "EHLO mail-it1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728869AbfC2OiI (ORCPT ); Fri, 29 Mar 2019 10:38:08 -0400 Received: by mail-it1-f193.google.com with SMTP id y204so4046996itf.3 for ; Fri, 29 Mar 2019 07:38:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=eQpIfLC+fwJsGVmnvxqsf2yilFvyJXO22CqcFpk5C2Q=; b=jdY5yGzwcPXdlQ6i38rqoB3F+Jwwm4cXR0VBag/rlf4Qr7G1tK+E44I4QKQIup+Tsc wV5JuUYQAt8E4F2ejUv7bcr5Tz/1kfkbq9sInTIz29z161GV4iEdbuSdUOvfIzy+YSUg YIxQJppMoUoLkSM1P6Y4eOnvCwp8HFSzaPxbwwvz/GLHlUFC7RaNFmrR2iUGDJQS60RS CCEjAeXJ9vSh5bUhVaZxudGZrjKOrKy/2Ufp1p+XF9unwLm3xfy//b8zA4VN6AmdcPmx DjllZctSSUi4P8XZoK3y3oc0msBEg3oxwM9VSyOtyfrWPxDrgyDVeuL3yC6WMnS7df/s xT9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=eQpIfLC+fwJsGVmnvxqsf2yilFvyJXO22CqcFpk5C2Q=; b=kGXNLTuy0zdO+IiNhgEUSDl942PE8FF8Fkf3g+fBkz0llnq907LyJetPAxeOvcG0ev e7hPe0KCiKrTzWb6lFnh4wGcru2flM+kSoE6erDBdJyTv9szbI/zAqqgDGfot4qNjyXW J1KPcqq9op0lUCf4Joj0upDPYwMiGhY5X+LyJ81nGbVlNQiuXWXz2owLnGP2QPBH5AIz vbDZXjKoEJj2jQWFK4QcOLTsCEkXH1enJAHbB2I4220eCWPFkTTa2naqZ6ZjibujF55H baD8X5FmS9VopKvskInaInSGDFWFP/uL41AbuL+Ai1fesYD+EpH+yzEcAm7XwbHXV//r h1wA== X-Gm-Message-State: APjAAAXncLKovIf1IOIRovPrYcKAEil1oALw4/WC+z33IXYjo/7y7/wK YA6yXahQa5015Q94y3DaFXh2qg== X-Google-Smtp-Source: APXvYqymxhrY7ZRiInV8U9y/4jALhw8KuSa7dnsjxt1QTcn+q2mkrIOCwgyIJMYReHoz2DpHsBQ0cg== X-Received: by 2002:a05:6638:1a:: with SMTP id z26mr34038518jao.99.1553870287551; Fri, 29 Mar 2019 07:38:07 -0700 (PDT) Received: from [192.168.1.158] ([216.160.245.98]) by smtp.gmail.com with ESMTPSA id j66sm1060135itb.38.2019.03.29.07.38.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Mar 2019 07:38:05 -0700 (PDT) Subject: Re: [PATCH v3 2/3] block: verify data when endio To: "Martin K. Petersen" Cc: Bob Liu , linux-block@vger.kernel.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, shirley.ma@oracle.com, allison.henderson@oracle.com, david@fromorbit.com, darrick.wong@oracle.com, hch@infradead.org, adilger@dilger.ca, tytso@mit.edu References: <20190329142346.1677-1-bob.liu@oracle.com> <20190329142346.1677-3-bob.liu@oracle.com> <41c8688a-65bd-96ac-9b23-4facd0ade4a7@kernel.dk> From: Jens Axboe Message-ID: Date: Fri, 29 Mar 2019 08:38:04 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On 3/29/19 8:34 AM, Martin K. Petersen wrote: > > Jens, > >> I told you this for the initial posting, and the objection still >> stands. Adding 40 bytes to struct bio is a no-go. >> >> So that's a big NAK on that series. > > I think you missed Bob's comment that this will go in the existing > bio_integrity field. I believe the main purpose of the series is to > solicit feedback on the callback approach. I didn't miss that, but it fixes nothing. That will unify the 40 bytes with 8 bytes, we're still growing the bio by a LOT. And we can't even nicely hide this behind some ifdef, sine distros enable everything and hence we're solving nothing by doing that. One potential solution could be to setup a specific bio_set for this, and allocate your read bios out of that. Growing struct bio by an enormous amount for this is just a non-starter to begin with, end of story. -- Jens Axboe