linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Ritesh Harjani <riteshh@linux.ibm.com>
Cc: Christoph Hellwig <hch@lst.de>,
	linux-ext4@vger.kernel.org, viro@zeniv.linux.org.uk,
	jack@suse.cz, tytso@mit.edu, adilger@dilger.ca,
	amir73il@gmail.com, linux-fsdevel@vger.kernel.org,
	linux-unionfs@vger.kernel.org
Subject: Re: [PATCH 07/11] iomap: fix the iomap_fiemap prototype
Date: Tue, 5 May 2020 12:29:14 +0200	[thread overview]
Message-ID: <20200505102914.GA15815@lst.de> (raw)
In-Reply-To: <20200501233402.5101BAE045@d06av26.portsmouth.uk.ibm.com>

On Sat, May 02, 2020 at 05:04:01AM +0530, Ritesh Harjani wrote:
>
>
> On 4/27/20 11:49 PM, Christoph Hellwig wrote:
>> iomap_fiemap should take u64 start and len arguments, just like the
>> ->fiemap prototype.
>>
>> Signed-off-by: Christoph Hellwig <hch@lst.de>
>
> hmm.. I guess,
> it's only ->fiemap ops in inode_operations which has
> start and len arguments as u64.
>
> While such other ops in struct file_operations have the
> arguments of type loff_t. (e.g. ->fallocate, -->llseek etc).
>
> But sure to match the ->fiemap prototype, this patch looks ok to me.

Yes, fiemap is rather weird here, but it matches the ioctl prototype,
so I'd rather pass it on to the method where fiemap_prep will catch
anything that overflows s_maxbytes due to the signeness of loff_t.

  reply	other threads:[~2020-05-05 10:29 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-27 18:19 fix fiemap for ext4 bitmap files (+ cleanups) v2 Christoph Hellwig
2020-04-27 18:19 ` [PATCH 01/11] ext4: fix EXT4_MAX_LOGICAL_BLOCK macro Christoph Hellwig
2020-04-27 18:19 ` [PATCH 02/11] ext4: fix fiemap size checks for bitmap files Christoph Hellwig
2020-05-01 23:20   ` Ritesh Harjani
2020-04-27 18:19 ` [PATCH 03/11] ext4: split _ext4_fiemap Christoph Hellwig
2020-05-01 23:21   ` Ritesh Harjani
2020-04-27 18:19 ` [PATCH 04/11] ext4: remove the call to fiemap_check_flags in ext4_fiemap Christoph Hellwig
2020-05-01 23:21   ` Ritesh Harjani
2020-04-27 18:19 ` [PATCH 05/11] fs: mark __generic_block_fiemap static Christoph Hellwig
2020-04-28 15:06   ` Darrick J. Wong
2020-05-01 23:22   ` Ritesh Harjani
2020-04-27 18:19 ` [PATCH 06/11] fs: move the fiemap definitions out of fs.h Christoph Hellwig
2020-04-28 15:07   ` Darrick J. Wong
2020-05-01 23:23   ` Ritesh Harjani
2020-04-27 18:19 ` [PATCH 07/11] iomap: fix the iomap_fiemap prototype Christoph Hellwig
2020-04-28 15:08   ` Darrick J. Wong
2020-05-01 23:34   ` Ritesh Harjani
2020-05-05 10:29     ` Christoph Hellwig [this message]
2020-04-27 18:19 ` [PATCH 08/11] fs: move fiemap range validation into the file systems instances Christoph Hellwig
2020-04-28  2:35   ` Amir Goldstein
2020-04-28 15:14   ` Darrick J. Wong
2020-05-01 22:49   ` Ritesh Harjani
2020-05-05 10:37     ` Christoph Hellwig
2020-04-27 18:19 ` [PATCH 09/11] fs: handle FIEMAP_FLAG_SYNC in fiemap_prep Christoph Hellwig
2020-04-28  2:26   ` Amir Goldstein
2020-04-28 15:16   ` Darrick J. Wong
2020-05-01 22:52   ` Ritesh Harjani
2020-05-05 10:43     ` Christoph Hellwig
2020-04-27 18:19 ` [PATCH 10/11] fs: remove the access_ok() check in ioctl_fiemap Christoph Hellwig
2020-04-28 15:21   ` Darrick J. Wong
2020-05-05 10:44     ` Christoph Hellwig
2020-05-01 22:56   ` Ritesh Harjani
2020-04-27 18:19 ` [PATCH 11/11] ext4: remove the access_ok() check in ext4_ioctl_get_es_cache Christoph Hellwig
2020-05-01 22:56   ` Ritesh Harjani
2020-05-05 15:43 fix fiemap for ext4 bitmap files (+ cleanups) v3 Christoph Hellwig
2020-05-05 15:43 ` [PATCH 07/11] iomap: fix the iomap_fiemap prototype Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200505102914.GA15815@lst.de \
    --to=hch@lst.de \
    --cc=adilger@dilger.ca \
    --cc=amir73il@gmail.com \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=riteshh@linux.ibm.com \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).