From: Carlos Maiolino <cmaiolino@redhat.com>
To: linux-fsdevel@vger.kernel.org
Cc: hch@lst.de
Subject: [PATCH 0/5] Refactor ioctl_fibmap() internal interface
Date: Tue, 10 Dec 2019 16:03:39 +0100 [thread overview]
Message-ID: <20191210150344.112181-1-cmaiolino@redhat.com> (raw)
Hi,
This series refactor the internal structure of FIBMAP so that the filesystem can
properly report errors back to VFS, and also simplifies its usage by
standardizing all ->bmap() method usage via bmap() function.
The last patch is a bug fix for ioctl_fibmap() calls with negative block values.
This new version just includes small kbuild test robot warnings caused by
ommited parameter names, and remove changelogs from patches description, moving
them to this cover-letter.
Changelog:
V7:
- Rebased over linux-next
- Add parameters names to function declarations
Reported-by: kbuild test robot <lkp@intel.com>
- Remove changelog entries from patches's commit logs
V6:
- Add a dummy bmap() definition so build does not break if
CONFIG_BLOCK is not set
Reported-by: kbuild test robot <lkp@intel.com>
- ASSERT only if filesystem does not support bmap() to
match the original logic
- Fix bmap() doc function
Reported-by: kbuild test robot <lkp@intel.com>
V5:
- Rebasing against 5.3 required changes to the f2fs
check_swap_activate() function
V4:
- Ensure ioctl_fibmap() returns 0 in case of error returned from
bmap(). Otherwise we'll be changing the user interface (which
returns 0 in case of error)
V3:
- Rename usr_blk to ur_block
V2:
- Use a local sector_t variable to asign the block number
instead of using direct casting.
Carlos Maiolino (5):
fs: Enable bmap() function to properly return errors
cachefiles: drop direct usage of ->bmap method.
ecryptfs: drop direct calls to ->bmap
fibmap: Use bmap instead of ->bmap method in ioctl_fibmap
fibmap: Reject negative block numbers
drivers/md/md-bitmap.c | 16 ++++++++++------
fs/cachefiles/rdwr.c | 27 ++++++++++++++-------------
fs/ecryptfs/mmap.c | 16 ++++++----------
fs/f2fs/data.c | 16 +++++++++++-----
fs/inode.c | 30 +++++++++++++++++-------------
fs/ioctl.c | 32 ++++++++++++++++++++++----------
fs/jbd2/journal.c | 22 +++++++++++++++-------
include/linux/fs.h | 9 ++++++++-
mm/page_io.c | 11 +++++++----
9 files changed, 110 insertions(+), 69 deletions(-)
--
2.23.0
next reply other threads:[~2019-12-10 15:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-10 15:03 Carlos Maiolino [this message]
2019-12-10 15:03 ` [PATCH 1/5] fs: Enable bmap() function to properly return errors Carlos Maiolino
2019-12-10 15:03 ` [PATCH 2/5] cachefiles: drop direct usage of ->bmap method Carlos Maiolino
2019-12-10 15:03 ` [PATCH 3/5] ecryptfs: drop direct calls to ->bmap Carlos Maiolino
2019-12-10 15:03 ` [PATCH 4/5] fibmap: Use bmap instead of ->bmap method in ioctl_fibmap Carlos Maiolino
2019-12-10 15:03 ` [PATCH 5/5] fibmap: Reject negative block numbers Carlos Maiolino
-- strict thread matches above, loose matches on Subject: below --
2019-11-22 8:53 [PATCH 0/5] Refactor ioctl_fibmap() internal interface Carlos Maiolino
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=20191210150344.112181-1-cmaiolino@redhat.com \
--to=cmaiolino@redhat.com \
--cc=hch@lst.de \
--cc=linux-fsdevel@vger.kernel.org \
/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).