linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/3] Replace direct ->bmap calls by bmap() with error support
@ 2018-09-12 12:25 Carlos Maiolino
  2018-09-12 12:25 ` [PATCH 1/3] fs: Enable bmap() function to properly return errors Carlos Maiolino
                   ` (2 more replies)
  0 siblings, 3 replies; 13+ messages in thread
From: Carlos Maiolino @ 2018-09-12 12:25 UTC (permalink / raw)
  To: linux-fsdevel; +Cc: hch, sandeen, david

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2018-09-18 11:31 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-09-12 12:25 [PATCH 0/3] Replace direct ->bmap calls by bmap() with error support Carlos Maiolino
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

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).