From patchwork Tue Aug 28 00:03:15 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Omar Sandoval X-Patchwork-Id: 10577693 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id E1AF9920 for ; Tue, 28 Aug 2018 00:03:52 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D908F29DA9 for ; Tue, 28 Aug 2018 00:03:52 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id CD6BA29DAD; Tue, 28 Aug 2018 00:03:52 +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=-2.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI 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 6D0D029DCF for ; Tue, 28 Aug 2018 00:03:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727317AbeH1Dw0 (ORCPT ); Mon, 27 Aug 2018 23:52:26 -0400 Received: from mail-pf1-f194.google.com ([209.85.210.194]:43033 "EHLO mail-pf1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727206AbeH1DwZ (ORCPT ); Mon, 27 Aug 2018 23:52:25 -0400 Received: by mail-pf1-f194.google.com with SMTP id j26-v6so319089pfi.10 for ; Mon, 27 Aug 2018 17:03:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osandov-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=WYtZJ9j6HlKXTuJDNIAj8/2V/JaRZVSBJ8+XtmMKMac=; b=lGwdQgbCxfaXG5B5y3gkyJGEHHEV7AWTYcdchnCYz3qwBV0GMrtlHS8I4uwKuDqUY+ MR7wDlckn6Qu9/86+rq5lIebE3bmjfpdo4mfpmtSg+iqRcl2EBYJ4/bZA9kE4YGYv1Ia feYscw1qJotCj6UjBIojzNsvdyWBi94XlfF0oQ+HPCZrmD2BRvsjAtquDJ4u9c2GkeGN maTa+c+7C7ub2SbDq87IHWSr6rvU8tsGW47+49xrIDcALBSSR6/juZoxpVf5wZx5z0u+ ksH1uzU6UqshNZfySXBEBlRWdj384NNu8Iigg70AXwpPHKi9EeyAkv9Pf53IBO4TPnup ETkg== 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:in-reply-to :references; bh=WYtZJ9j6HlKXTuJDNIAj8/2V/JaRZVSBJ8+XtmMKMac=; b=UzCMVoClOFBIehEjNWAyC43Tps1DiSjlT9cvBpsKysQuw25kJxlsjSQ84HbRHwiMUm YaDyg4ctRNT6RzMSPoTjvCJd8z9Kcwi1l3LsH+YrodhOcEWGOT19WI5Ti56HbNS/YcPw VYZ3Cmots3x77WHayTZklkNfT1pYE6/3uIalze4ilqnOsZ6kmDsQjSADdavq+1xW8NDC kXjiFJYgbj+sZlKek37r65IlY/f4AWYoNnqWeYD+603AaWuTxS1zJZuTuGfmpS/PlK+M ZLRckEfP4/sx0Uo9zedZHzDpjg3japLmbL4tIUYuSVxTPlr9624jKlDzH3znOMeTVeO+ Re2w== X-Gm-Message-State: APzg51B5R2XqDql+KJ4LF5XqsTN/Ste0TbUrhhIN7dyczB26ro7hY0aS rImzeSP16AjXHdWg/70rFjEK49QH7ss= X-Google-Smtp-Source: ANB0VdaPbdBk+7v/rNecxDefMnCDK+GeyKu/cM8TH8uY2H1YsFUCv6cTytjO2LL7B0hJ4+WgYCTcCQ== X-Received: by 2002:a63:ff54:: with SMTP id s20-v6mr12528021pgk.241.1535414610888; Mon, 27 Aug 2018 17:03:30 -0700 (PDT) Received: from vader.thefacebook.com ([2620:10d:c090:200::7:5f0c]) by smtp.gmail.com with ESMTPSA id z22-v6sm455315pgc.67.2018.08.27.17.03.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Aug 2018 17:03:30 -0700 (PDT) From: Omar Sandoval To: linux-fsdevel@vger.kernel.org, linux-btrfs@vger.kernel.org, Al Viro Cc: David Sterba , kernel-team@fb.com, "Theodore Ts'o" , Andreas Dilger Subject: [RFC PATCH v2 2/6] ext4: use iocb->private instead of bh->b_private Date: Mon, 27 Aug 2018 17:03:15 -0700 Message-Id: <344cfe9b7dfc03ccfde2bf28c1ac74ec887cdc0d.1535414064.git.osandov@fb.com> X-Mailer: git-send-email 2.18.0 In-Reply-To: References: Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Omar Sandoval As part of simplifying all of the private data passed around for direct I/O, bh->b_private will no longer be passed to dio_iodone_t. iocb is still available there, however, so convert ext4 to use it. Note that ext4_file_write_iter() also uses iocb->private, but ext4_direct_IO_write() resets it to NULL after reading it. Also note that the comment above ext4_should_dioread_nolock() is no longer accurate. It seems that it should be possible to remove the data journaling restriction now? Cc: "Theodore Ts'o" Cc: Andreas Dilger Signed-off-by: Omar Sandoval --- fs/ext4/inode.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 18ad91b1c8f6..841d79919cef 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -884,18 +884,16 @@ static int ext4_dio_get_block_unwritten_async(struct kiocb *iocb, /* * When doing DIO using unwritten extents, we need io_end to convert * unwritten extents to written on IO completion. We allocate io_end - * once we spot unwritten extent and store it in b_private. Generic - * DIO code keeps b_private set and furthermore passes the value to - * our completion callback in 'private' argument. + * once we spot unwritten extent and store it in iocb->private. */ if (!ret && buffer_unwritten(bh_result)) { - if (!bh_result->b_private) { + if (!iocb->private) { ext4_io_end_t *io_end; io_end = ext4_init_io_end(inode, GFP_KERNEL); if (!io_end) return -ENOMEM; - bh_result->b_private = io_end; + iocb->private = io_end; ext4_set_io_unwritten_flag(inode, io_end); } set_buffer_defer_completion(bh_result); @@ -3617,7 +3615,7 @@ const struct iomap_ops ext4_iomap_ops = { static int ext4_end_io_dio(struct kiocb *iocb, loff_t offset, ssize_t size, void *private) { - ext4_io_end_t *io_end = private; + ext4_io_end_t *io_end = iocb->private; /* if not async direct IO just return */ if (!io_end)