All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Guoqing Jiang <guoqing.jiang@cloud.ionos.com>
Cc: Dave Chinner <david@fromorbit.com>, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 0/5] export __clear_page_buffers to cleanup code
Date: Mon, 20 Apr 2020 15:14:24 -0700	[thread overview]
Message-ID: <20200420221424.GH5820@bombadil.infradead.org> (raw)
In-Reply-To: <e889cb45-486b-118c-d087-90fed5353460@cloud.ionos.com>

On Mon, Apr 20, 2020 at 11:14:35PM +0200, Guoqing Jiang wrote:
> On 20.04.20 02:30, Matthew Wilcox wrote:
> > On Mon, Apr 20, 2020 at 09:20:46AM +1000, Dave Chinner wrote:
> > > Anyone expecting to use set/clear_page_private as a matched pair (as
> > > the names suggest they are) is in for a horrible surprise...
> 
> Dave, thanks for the valuable suggestion!
> 
> > Oh, blast.  I hadn't noticed that.  And we're horribly inconsistent
> > with how we use set_page_private() too -- rb_alloc_aux_page() doesn't
> > increment the page's refcount, for example.
> > 
> > So, new (pair of) names:
> > 
> > set_fs_page_private()
> > clear_fs_page_private()
> 
> Hmm, maybe it is better to keep the original name (set/clear_page_private).

No.  Changing the semantics of set_page_private() without changing the
function signature is bad because it makes patches silently break when
applied to trees on either side of the change.  So we need a new name.

> 1. it would be weird for other subsystems (not belong to fs scope) to call
> the
> function which is supposed to be used in fs, though we can add a wrapper
> for other users out of fs.
> 
> 2. no function in mm.h is named like *fs*.

perhaps it should be in pagemap.h since it's for pagecache pages.

> > since it really seems like it's only page cache pages which need to
> > follow the rules about setting PagePrivate and incrementing the refcount.
> > Also, I think I'd like to see them take/return a void *:
> > 
> > void *set_fs_page_private(struct page *page, void *data)
> > {
> > 	get_page(page);
> > 	set_page_private(page, (unsigned long)data);
> > 	SetPagePrivate(page);
> > 	return data;
> > }
> 
> Seems  some functions could probably use the above helper, such as
> iomap_page_create, iomap_migrate_page, get_page_bootmem and
>  f2fs_set_page_private etc.

Yes.

> Really appreciate for your input though the thing is a little beyond my
> original intention ;-), will try to send a new version after reading more
> fs code.

That's kind of the way things go ... you start pulling on one thread
and all of a sudden, you're weaving a new coat ;-)

  reply	other threads:[~2020-04-20 22:14 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-18 22:51 [PATCH 0/5] export __clear_page_buffers to cleanup code Guoqing Jiang
2020-04-18 22:51 ` [PATCH 1/5] fs/buffer: export __clear_page_buffers Guoqing Jiang
2020-04-19  7:56   ` Nikolay Borisov
2020-04-19 13:20     ` Guoqing Jiang
2020-04-18 22:51 ` [PATCH 2/5] btrfs: call __clear_page_buffers to simplify code Guoqing Jiang
2020-04-19 19:46   ` David Sterba
2020-04-19 20:32     ` Guoqing Jiang
2020-04-18 22:51 ` [PATCH 3/5] iomap: call __clear_page_buffers in iomap_page_release Guoqing Jiang
2020-04-19  7:47   ` Christoph Hellwig
2020-04-19 13:18     ` Guoqing Jiang
2020-04-18 22:51 ` [RFC PATCH 4/5] orangefs: call __clear_page_buffers to simplify code Guoqing Jiang
2020-04-18 22:51 ` [PATCH 5/5] md-bitmap: don't duplicate code for __clear_page_buffers Guoqing Jiang
2020-04-19  3:14 ` [PATCH 0/5] export __clear_page_buffers to cleanup code Matthew Wilcox
2020-04-19  5:14   ` Gao Xiang
2020-04-19 13:22     ` Guoqing Jiang
2020-04-19 13:15   ` Guoqing Jiang
2020-04-19 20:31   ` Guoqing Jiang
2020-04-19 21:17     ` Matthew Wilcox
2020-04-19 23:20   ` Dave Chinner
2020-04-20  0:30     ` Matthew Wilcox
2020-04-20 21:14       ` Guoqing Jiang
2020-04-20 22:14         ` Matthew Wilcox [this message]
2020-04-21  1:53       ` Dave Chinner

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=20200420221424.GH5820@bombadil.infradead.org \
    --to=willy@infradead.org \
    --cc=david@fromorbit.com \
    --cc=guoqing.jiang@cloud.ionos.com \
    --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 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.