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]:50880 "EHLO newverein.lst.de"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S2389998AbeKQCUb (ORCPT <rfc822;linux-fsdevel@vger.kernel.org>);
        Fri, 16 Nov 2018 21:20:31 -0500
Date: Fri, 16 Nov 2018 17:07:32 +0100
From: Christoph Hellwig <hch@lst.de>
To: Carlos Maiolino <cmaiolino@redhat.com>
Cc: linux-fsdevel@vger.kernel.org, sandeen@redhat.com, hch@lst.de,
        david@fromorbit.com, darrick.wong@oracle.com
Subject: Re: [PATCH 20/20] ext4: Get rid of ->bmap interface
Message-ID: <20181116160732.GC17130@lst.de>
References: <20181030131823.29040-1-cmaiolino@redhat.com> <20181030131823.29040-21-cmaiolino@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20181030131823.29040-21-cmaiolino@redhat.com>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

> -	if (EXT4_JOURNAL(inode) &&
> -	    ext4_test_inode_state(inode, EXT4_STATE_JDATA)) {
> -		/*
> -		 * This is a REALLY heavyweight approach, but the use of
> -		 * bmap on dirty files is expected to be extremely rare:
> -		 * only if we run lilo or swapon on a freshly made file
> -		 * do we expect this to happen.
> -		 *
> -		 * (bmap requires CAP_SYS_RAWIO so this does not
> -		 * represent an unprivileged user DOS attack --- we'd be
> -		 * in trouble if mortal users could trigger this path at
> -		 * will.)
> -		 *
> -		 * NB. EXT4_STATE_JDATA is not set on files other than
> -		 * regular files.  If somebody wants to bmap a directory
> -		 * or symlink and gets confused because the buffer
> -		 * hasn't yet been flushed to disk, they deserve
> -		 * everything they get.
> -		 */

Does the ext4 fiemap code have this magic handling?  If not are
we sure we can kill it?