Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp767268imm; Fri, 21 Sep 2018 08:00:25 -0700 (PDT) X-Google-Smtp-Source: ANB0VdaidTxbfbyQKvKq0g3Ne5VljAg2ePg9/D1ST3g4i3BK0wwwwGJ7okkmZSHiCs7PWvCvBOXs X-Received: by 2002:a65:654d:: with SMTP id a13-v6mr41166267pgw.35.1537542025777; Fri, 21 Sep 2018 08:00:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537542025; cv=none; d=google.com; s=arc-20160816; b=0Kyn6ljDbAAPlmS/t40QtaRKuEJltkVqis0RSd3d2TOyCE3Cq3+vViOZ/0vPOnMADW AAuWcCuKttvCuTOgcNk7rH4WxW/oTYgFSh6TCP009pcoN5swK0eHcpFIRMgX/P57GpLF zMv0X3YWhkWc9H42DQJmXU+LJK3cgDUBmVurCAq9Z6GgIvz8LxGTd3cujOADlDP/AEpS XY1gOf0p4Be3tzKGtwu+06NF4jvAlmc5VUx54pNSikJVQOY6potdmClDGtd5+aryH4up Kftq6xn9s+x1SVf2UXnCRFzRtiCCjczphWGkkEn0h96Juzara3/sBsIY3zpXS/6DgCIn C0RQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=jamrnX0sFRvEHJX20QnT1GhwLyV16WnRhGsixsSTKqY=; b=DlRYD37uSYsgsup/1YsqJmeg5yHhepbGsQ4wpxX9AxKMJr9rEy4/hGdOIelqPn8erF PFsztaE6qih/TwvT01Zr0XFKH/np+ApJZlIxc6cEUB11snckDequ3d00heQ9gxYBg1Zw MUE7D7dRZCI/JIRuYHvu7+nDH6/kkqF+tLwb8ckv+a9XoiQngdwLLKwln03ia4GNo0C5 yq95NQKNNYZCtmw/DgTpUGlsIVUrnTF0lfkAJXmXtDcw4raNCRnpJSxmbCDXnKcLA5vr y4kCqF1seNlIpL5toPIwb7U6hiQzIceTzzsm0pzON4rRv9c8AuTEu891/EXfwHGgor4Y iEsw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b=0uIrF0+K; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u10-v6si26058675plr.58.2018.09.21.08.00.10; Fri, 21 Sep 2018 08:00:25 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b=0uIrF0+K; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390281AbeIUUtQ (ORCPT + 99 others); Fri, 21 Sep 2018 16:49:16 -0400 Received: from mail-it1-f178.google.com ([209.85.166.178]:51355 "EHLO mail-it1-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390231AbeIUUtQ (ORCPT ); Fri, 21 Sep 2018 16:49:16 -0400 Received: by mail-it1-f178.google.com with SMTP id e14-v6so2278490itf.1 for ; Fri, 21 Sep 2018 08:00:00 -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=jamrnX0sFRvEHJX20QnT1GhwLyV16WnRhGsixsSTKqY=; b=0uIrF0+KvQ8ImRKGV0by01j6c/FUCS2hKuX+/eVRSRq1SRsR/NC7O5mHOcBLIbBe+E zNZJbtC4INjqgPBd2uXkviIi8Wazo7f49zsgpg+y0ex+nstTe0UJOv8r86w4pmMRq1pk AbgBSeFZYm1VZLjN/Q82Flw2RnfIGxTpRyODmmxROgP6LE+N+SbQO2CJn4mqVVU8iGTs D6/P4zZUfeUartmQCMAoaxOO1B6Q0HUwS70t/n4eBYTTPLdMmZNMTQnexVAJDtwwafR2 gfsSkH8prUWyng6hUsuuK0JnbnbjuBjOZSU/qzh9O2/u/Qc3rNMcaBJuexe/qJyE9hVu k3Zg== 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=jamrnX0sFRvEHJX20QnT1GhwLyV16WnRhGsixsSTKqY=; b=LcigR4s4VkIrT6CddTJdk2aeLG6Z7E4Scv/OqSAVJo6PF0ImYxMzaHp5ry8ioyMEGX 0WUFW+C4iuq0dXJdPwcqdDLRUghGR8WK9F/t3NGwgbMpkko1MerjkuBIrmnJ1Hwf1Uuz /I4ZiXZSOgdrmUPza5X4LZEHplbU4lANWDqsXb3hxib5h5GfoDWYWasZZVT49miUSrda nFzQNHdMWebh6+GJVWWSLJRYcjnWdiRzb7ryH30y0Ywo79jhgVDNffr+HJQWJtizszvC 2djuXBkZL4A5gDIXwyn86X6SQas5fuQJldolzRLNI7pGqVIm2NpGwD+52BWxaLzbg7hb y9Xg== X-Gm-Message-State: ABuFfojmVBaP8uj4agPQDjAZUhKgfSmcJG6tJqZ33qjeWECQRuKNqb5d ncSZjRqpcV0zZ7f7eI7s9gCV3AjBmOY= X-Received: by 2002:a24:ecc4:: with SMTP id g187-v6mr1827473ith.145.1537541999939; Fri, 21 Sep 2018 07:59:59 -0700 (PDT) Received: from [192.168.1.56] ([216.160.245.98]) by smtp.gmail.com with ESMTPSA id t134-v6sm2420845itb.41.2018.09.21.07.59.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Sep 2018 07:59:58 -0700 (PDT) Subject: Re: block: DMA alignment of IO buffer allocated from slab To: Ming Lei , Christoph Hellwig Cc: Dave Chinner , Ming Lei , linux-block , linux-mm , Linux FS Devel , "open list:XFS FILESYSTEM" , Dave Chinner , Vitaly Kuznetsov , Linux Kernel Mailing List References: <20180921015608.GA31060@dastard> <20180921070805.GC14529@lst.de> <20180921072511.GA8188@ming.t460p> From: Jens Axboe Message-ID: <65999732-fc76-bb86-65ed-01aace49b9c7@kernel.dk> Date: Fri, 21 Sep 2018 08:59:57 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180921072511.GA8188@ming.t460p> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/21/18 1:25 AM, Ming Lei wrote: > On Fri, Sep 21, 2018 at 09:08:05AM +0200, Christoph Hellwig wrote: >> On Fri, Sep 21, 2018 at 11:56:08AM +1000, Dave Chinner wrote: >>>> 3) If slab can't guarantee to return 512-aligned buffer, how to fix >>>> this data corruption issue? >>> >>> I think that the block layer needs to check the alignment of memory >>> buffers passed to it and take appropriate action rather than >>> corrupting random memory and returning a sucess status to the bad >>> bio. >> >> Or just reject the I/O. But yes, we already have the >> queue_dma_alignment helper in the block layer, we just don't do it >> in the fast path. I think generic_make_request_checks needs to >> check it, and print an error and return a warning if the alignment >> requirement isn't met. > > That can be done in generic_make_request_checks(), but some cost may be > introduced, because each bvec needs to be checked in the fast path. I think this is all crazy talk. We've never done this, we've always assumed that an address of length N, will be N aligned as well. If a driver sets queue dma alignment > than its sector size, then we're in real trouble and would need to bounce IOs. That's silly enough that it doesn't warrant being done in the core code imho, if you're hw is that crappy, then do it in your queue_rq(). Could be done with a core helper for sure, but I'm really not that interested in having a full bvec loop for each bio just to check something that (to my knowledge) hasn't been an issue in decades. -- Jens Axboe