From patchwork Wed Sep 12 12:25:33 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Carlos Maiolino X-Patchwork-Id: 10597415 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 3D78B920 for ; Wed, 12 Sep 2018 12:25:53 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 295B629D26 for ; Wed, 12 Sep 2018 12:25:53 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 1C80629D44; Wed, 12 Sep 2018 12:25:53 +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=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI 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 AD2E029D26 for ; Wed, 12 Sep 2018 12:25:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726754AbeILRaJ (ORCPT ); Wed, 12 Sep 2018 13:30:09 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:44524 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726491AbeILRaJ (ORCPT ); Wed, 12 Sep 2018 13:30:09 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F0685E9006; Wed, 12 Sep 2018 12:25:50 +0000 (UTC) Received: from odin.brq.redhat.com (unknown [10.43.17.217]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1DBE62166BA3; Wed, 12 Sep 2018 12:25:47 +0000 (UTC) From: Carlos Maiolino To: linux-fsdevel@vger.kernel.org Cc: hch@lst.de, sandeen@redhat.com, david@fromorbit.com Subject: [PATCH 0/3] Replace direct ->bmap calls by bmap() with error support Date: Wed, 12 Sep 2018 14:25:33 +0200 Message-Id: <20180912122536.31977-1-cmaiolino@redhat.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Wed, 12 Sep 2018 12:25:51 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Wed, 12 Sep 2018 12:25:51 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'cmaiolino@redhat.com' RCPT:'' Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi, this is a non-RFC version of the attempt to replace direct ->bmap() calls by calls to bmap() helper. This is a preparatory work to remove ->bmap() interface in a not so distant future. I decided to send this replacement separated from everything else, because I want to make sure to get the ->bmap replacement correct before doing work which will rely on it. This also enables bmap() helper to properly return an error, as, by now, ->bmap() uses '0' as an error return. With this patchset, the following behavior is set: int bmap(struct inode *, sector_t *); the passed pointer sector_t* will be changed internally and after return, will contain either the physical block number of the requested mapping, or 0, if it falls into a hole. The return value is either a negative in case of error, or 0. The ability of bmap() to return an error, has been suggested by Christoph, and this is based on his suggestion, with small modifications. Also, with the ability to return errors, Eric Sandeen suggested we may actually use it to return -EOVERFLOW in ioctl_fibmap() calls, to signal userspace the requested value has been truncated, since, by now, there is no easy way for it to be detected. Once I can get this patchset properly set, I'll work on needed modifications into ->bmap() itself. I did split the ->bmap() to bmap() replacements into different patches, separated by projects, because I thought it would be easier to review, I do apologize if I should have added everything into a single patch. I also didn't change ioctl_fibmap(), because for me at least, it makes more sense to call ->bmap() there directly by now, so we we avoid copying the userspace data if the method doesn't even exist. Comments are appreciated. Cheers. Carlos Maiolino (3): fs: Enable bmap() function to properly return errors cachefiles: drop direct usage of ->bmap method. ecryptfs: drop direct calls to ->bmap drivers/md/md-bitmap.c | 16 ++++++++++------ fs/cachefiles/rdwr.c | 27 ++++++++++++++------------- fs/ecryptfs/mmap.c | 11 ++++++----- fs/inode.c | 30 +++++++++++++++++------------- fs/jbd2/journal.c | 22 +++++++++++++++------- include/linux/fs.h | 2 +- mm/page_io.c | 11 +++++++---- 7 files changed, 70 insertions(+), 49 deletions(-)