All of lore.kernel.org
 help / color / mirror / Atom feed
From: Carlos Maiolino <cmaiolino@redhat.com>
To: linux-fsdevel@vger.kernel.org
Cc: hch@lst.de, sandeen@redhat.com, david@fromorbit.com
Subject: [PATCH 0/3] Replace direct ->bmap calls by bmap() with error support
Date: Wed, 12 Sep 2018 14:25:33 +0200	[thread overview]
Message-ID: <20180912122536.31977-1-cmaiolino@redhat.com> (raw)

Hi, this is a non-RFC version of the attempt to replace direct ->bmap() calls
by calls to bmap() helper.

This is a preparatory work to remove ->bmap() interface in a not so distant
future.

I decided to send this replacement separated from everything else, because I
want to make sure to get the ->bmap replacement correct before doing work which
will rely on it.

This also enables bmap() helper to properly return an error, as, by now,
->bmap() uses '0' as an error return.

With this patchset, the following behavior is set:

int bmap(struct inode *, sector_t *);

the passed pointer sector_t* will be changed internally and after return, will
contain either the physical block number of the requested mapping, or 0, if it
falls into a hole.

The return value is either a negative in case of error, or 0.

The ability of bmap() to return an error, has been suggested by Christoph, and
this is based on his suggestion, with small modifications.

Also, with the ability to return errors, Eric Sandeen suggested we may actually
use it to return -EOVERFLOW in ioctl_fibmap() calls, to signal userspace the
requested value has been truncated, since, by now, there is no easy way for it
to be detected.

Once I can get this patchset properly set, I'll work on needed modifications
into ->bmap() itself.

I did split the ->bmap() to bmap() replacements into different patches,
separated by projects, because I thought it would be easier to review, I do
apologize if I should have added everything into a single patch.

I also didn't change ioctl_fibmap(), because for me at least, it makes more
sense to call ->bmap() there directly by now, so we we avoid copying the
userspace data if the method doesn't even exist.

Comments are appreciated.
Cheers.


Carlos Maiolino (3):
  fs: Enable bmap() function to properly return errors
  cachefiles: drop direct usage of ->bmap method.
  ecryptfs: drop direct calls to ->bmap

 drivers/md/md-bitmap.c | 16 ++++++++++------
 fs/cachefiles/rdwr.c   | 27 ++++++++++++++-------------
 fs/ecryptfs/mmap.c     | 11 ++++++-----
 fs/inode.c             | 30 +++++++++++++++++-------------
 fs/jbd2/journal.c      | 22 +++++++++++++++-------
 include/linux/fs.h     |  2 +-
 mm/page_io.c           | 11 +++++++----
 7 files changed, 70 insertions(+), 49 deletions(-)

-- 
2.14.4

             reply	other threads:[~2018-09-12 17:30 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-12 12:25 Carlos Maiolino [this message]
2018-09-12 12:25 ` [PATCH 1/3] fs: Enable bmap() function to properly return errors Carlos Maiolino
2018-09-14 13:23   ` Christoph Hellwig
2018-09-14 18:48     ` Carlos Maiolino
2018-09-17 20:55   ` Darrick J. Wong
2018-09-18  6:00     ` Carlos Maiolino
2018-09-12 12:25 ` [PATCH 2/3] cachefiles: drop direct usage of ->bmap method Carlos Maiolino
2018-09-14 13:23   ` Christoph Hellwig
2018-09-14 18:56     ` Carlos Maiolino
2018-09-12 12:25 ` [PATCH 3/3] ecryptfs: drop direct calls to ->bmap Carlos Maiolino
2018-09-14 13:26   ` Christoph Hellwig
2018-09-14 18:47     ` Carlos Maiolino
2018-09-17 11:04   ` [PATCH 3/3 V2] " 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=20180912122536.31977-1-cmaiolino@redhat.com \
    --to=cmaiolino@redhat.com \
    --cc=david@fromorbit.com \
    --cc=hch@lst.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=sandeen@redhat.com \
    /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.