All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ritesh Harjani <riteshh@linux.ibm.com>
To: linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
	"Darrick J . Wong" <darrick.wong@oracle.com>,
	Christoph Hellwig <hch@infradead.org>, Jan Kara <jack@suse.com>,
	tytso@mit.edu, "Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>,
	linux-ext4@vger.kernel.org,
	Ritesh Harjani <riteshh@linux.ibm.com>
Subject: [PATCH 0/2] WARN fibmap user in case of possible addr truncation
Date: Fri, 24 Apr 2020 12:52:16 +0530	[thread overview]
Message-ID: <cover.1587670914.git.riteshh@linux.ibm.com> (raw)

Currently an ioctl_fibmap() caller may get a truncated and wrong block map
address if the actual mapped physical block address is > INT_MAX.
If that is the case then lets:-
1. Add a warning,
2. Returns 0 in the block mapped address,
3. And also return -ERANGE error.
This is better than providing a wrong information to the user about the
block mapping which in the worst case could cause a FS corruption
(unknowingly by the caller since kernel didn't warn).
Currently these checks are in place only for the filesystems who uses iomap
based bmap interface. So let's do this right thing for all the fibmap()
callers by adding this logic in ioctl_fibmap() directly.

Patch-1 & Patch-2 commit msg may provide additional information.

Ritesh Harjani (2):
  fibmap: Warn and return an error in case of block > INT_MAX
  iomap: bmap: Remove the WARN and return the proper block address

 fs/ioctl.c        | 5 +++++
 fs/iomap/fiemap.c | 5 +----
 2 files changed, 6 insertions(+), 4 deletions(-)

-- 
2.21.0


             reply	other threads:[~2020-04-24  7:22 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-24  7:22 Ritesh Harjani [this message]
2020-04-24  7:22 ` [PATCH 1/2] fibmap: Warn and return an error in case of block > INT_MAX Ritesh Harjani
2020-04-24  9:57   ` Jan Kara
2020-04-24 10:07   ` Christoph Hellwig
2020-04-24 19:17   ` Eric Biggers
2020-04-24 22:54     ` Ritesh Harjani
2020-04-24 23:40       ` Matthew Wilcox
2020-04-24 23:46         ` Darrick J. Wong
2020-04-25  7:03           ` Ritesh Harjani
2020-04-27  1:04             ` Dave Chinner
2020-04-28  7:29               ` Ritesh Harjani
2020-04-24  7:22 ` [PATCH 2/2] iomap: bmap: Remove the WARN and return the proper block address Ritesh Harjani
2020-04-24  9:59   ` Jan Kara
2020-04-24 10:07   ` Christoph Hellwig
2020-04-24 17:48   ` Darrick J. Wong
2020-04-24 22:39     ` Ritesh Harjani

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=cover.1587670914.git.riteshh@linux.ibm.com \
    --to=riteshh@linux.ibm.com \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=darrick.wong@oracle.com \
    --cc=hch@infradead.org \
    --cc=jack@suse.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.