From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from verein.lst.de ([213.95.11.211]:57778 "EHLO newverein.lst.de"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1727972AbeINSko (ORCPT <rfc822;linux-fsdevel@vger.kernel.org>);
        Fri, 14 Sep 2018 14:40:44 -0400
Date: Fri, 14 Sep 2018 15:26:16 +0200
From: Christoph Hellwig <hch@lst.de>
To: Carlos Maiolino <cmaiolino@redhat.com>
Cc: linux-fsdevel@vger.kernel.org, hch@lst.de, sandeen@redhat.com,
        david@fromorbit.com
Subject: Re: [PATCH 3/3] ecryptfs: drop direct calls to ->bmap
Message-ID: <20180914132616.GC27382@lst.de>
References: <20180912122536.31977-1-cmaiolino@redhat.com> <20180912122536.31977-4-cmaiolino@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180912122536.31977-4-cmaiolino@redhat.com>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Wed, Sep 12, 2018 at 02:25:36PM +0200, Carlos Maiolino wrote:
>  static sector_t ecryptfs_bmap(struct address_space *mapping, sector_t block)
>  {
> +	sector_t blk_map = 0;
> +	int ret;
>  	struct inode *inode;
>  	struct inode *lower_inode;
>  
>  	inode = (struct inode *)mapping->host;
>  	lower_inode = ecryptfs_inode_to_lower(inode);
> +
> +	ret = bmap(lower_inode, &blk_map);
> +
> +	return !ret ? blk_map : 0;

This could be simplified to:

static sector_t ecryptfs_bmap(struct address_space *mapping, sector_t block)
{
 	struct inode *lower_inode = ecryptfs_inode_to_lower(mapping->host);
	int ret = bmap(lower_inode, &block);

	if (ret)
		return 0;
	return block;
}

But the idea that we even support ->bmap on ecryptfs sounds way too
dangerous.