From: Nick Piggin <npiggin@suse.de>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [rfc][patch] mm, fs: warn on missing address space operations
Date: Mon, 22 Mar 2010 22:33:17 +1100 [thread overview]
Message-ID: <20100322113317.GK17637@laptop> (raw)
In-Reply-To: <20100322110758.GA13690@infradead.org>
On Mon, Mar 22, 2010 at 07:07:58AM -0400, Christoph Hellwig wrote:
> > @@ -2472,7 +2472,14 @@ int try_to_release_page(struct page *pag
> >
> > if (mapping && mapping->a_ops->releasepage)
> > return mapping->a_ops->releasepage(page, gfp_mask);
> > - return try_to_free_buffers(page);
> > + else {
> > + static bool warned = false;
> > + if (!warned) {
> > + warned = true;
> > + print_symbol("address_space_operations %s missing releasepage method. Use try_to_free_buffers.\n", (unsigned long)page->mapping->a_ops);
> > + }
> > + return try_to_free_buffers(page);
> > + }
>
> I don't think this is correct. We currently also call
> try_to_free_buffers if the page does not have a mapping, and from
> conversations with Andrew long time ago that case actually does seem to
> be nessecary due to behaviour in ext3/jbd. So you really should
> only warn if there is a mapping to start with. In fact your code will
> dereference a potential NULL pointer in that case.
Good point.
I think some of that code is actually dead.
is_page_cache_freeable will check for the page reclaim reference,
the pagecache reference, and the PagePrivate reference.
If the page is removed from pagecache, that reference will be
dropped but is_page_cache_freeable() will not consider that and
fail.
NULL page can still come in there from buffer_heads_over_limit AFAIKS,
but if we are relying on that for freeing pages then it can break if a
lot of memory is tied up in other things.
That's all really ugly too. It means no other filesystem may take an
action to take in case of NULL page->mapping, which means it is really
the wrong thing to do. Fortunately fsblock has proper refcounting so it
would never need to handle this case.
>
> And as others said, this patch only makes sense after the existing
> filesystems are updated to fill out all methods, and for the case
> of try_to_free_buffers and set_page_dirty until we have suitable
> and well-named default operations available.
__set_page_dirty_nobuffers seems OK. Everyone has had to use that
until now anyway. Agreed about try_to_free_buffers.
>
> Btw, any reason this doesn't use the %pf specifier to printk
> instead of dragging in print_symbol? Even better would
> be to just print the fs type from mapping->host->i_sb->s_type->name.
Ah, because I didn't know about it. Thanks. Name I guess can be
ambiguous if there is more than one aop. I'll make it a macro and
print both maybe.
WARNING: multiple messages have this Message-ID (diff)
From: Nick Piggin <npiggin@suse.de>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [rfc][patch] mm, fs: warn on missing address space operations
Date: Mon, 22 Mar 2010 22:33:17 +1100 [thread overview]
Message-ID: <20100322113317.GK17637@laptop> (raw)
In-Reply-To: <20100322110758.GA13690@infradead.org>
On Mon, Mar 22, 2010 at 07:07:58AM -0400, Christoph Hellwig wrote:
> > @@ -2472,7 +2472,14 @@ int try_to_release_page(struct page *pag
> >
> > if (mapping && mapping->a_ops->releasepage)
> > return mapping->a_ops->releasepage(page, gfp_mask);
> > - return try_to_free_buffers(page);
> > + else {
> > + static bool warned = false;
> > + if (!warned) {
> > + warned = true;
> > + print_symbol("address_space_operations %s missing releasepage method. Use try_to_free_buffers.\n", (unsigned long)page->mapping->a_ops);
> > + }
> > + return try_to_free_buffers(page);
> > + }
>
> I don't think this is correct. We currently also call
> try_to_free_buffers if the page does not have a mapping, and from
> conversations with Andrew long time ago that case actually does seem to
> be nessecary due to behaviour in ext3/jbd. So you really should
> only warn if there is a mapping to start with. In fact your code will
> dereference a potential NULL pointer in that case.
Good point.
I think some of that code is actually dead.
is_page_cache_freeable will check for the page reclaim reference,
the pagecache reference, and the PagePrivate reference.
If the page is removed from pagecache, that reference will be
dropped but is_page_cache_freeable() will not consider that and
fail.
NULL page can still come in there from buffer_heads_over_limit AFAIKS,
but if we are relying on that for freeing pages then it can break if a
lot of memory is tied up in other things.
That's all really ugly too. It means no other filesystem may take an
action to take in case of NULL page->mapping, which means it is really
the wrong thing to do. Fortunately fsblock has proper refcounting so it
would never need to handle this case.
>
> And as others said, this patch only makes sense after the existing
> filesystems are updated to fill out all methods, and for the case
> of try_to_free_buffers and set_page_dirty until we have suitable
> and well-named default operations available.
__set_page_dirty_nobuffers seems OK. Everyone has had to use that
until now anyway. Agreed about try_to_free_buffers.
>
> Btw, any reason this doesn't use the %pf specifier to printk
> instead of dragging in print_symbol? Even better would
> be to just print the fs type from mapping->host->i_sb->s_type->name.
Ah, because I didn't know about it. Thanks. Name I guess can be
ambiguous if there is more than one aop. I'll make it a macro and
print both maybe.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2010-03-22 11:33 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-22 5:39 [rfc][patch] mm, fs: warn on missing address space operations Nick Piggin
2010-03-22 5:39 ` Nick Piggin
2010-03-22 4:56 ` Andrew Morton
2010-03-22 4:56 ` Andrew Morton
2010-03-22 8:00 ` Pekka Enberg
2010-03-22 8:00 ` Pekka Enberg
2010-03-22 10:40 ` Nick Piggin
2010-03-22 10:40 ` Nick Piggin
2010-03-22 13:30 ` Andrew Morton
2010-03-22 13:30 ` Andrew Morton
2010-03-22 21:01 ` Nick Piggin
2010-03-22 21:01 ` Nick Piggin
2010-03-22 9:17 ` Boaz Harrosh
2010-03-22 9:17 ` Boaz Harrosh
2010-03-22 10:54 ` Nick Piggin
2010-03-22 10:54 ` Nick Piggin
2010-03-22 12:05 ` Boaz Harrosh
2010-03-22 12:05 ` Boaz Harrosh
2010-03-22 11:07 ` Christoph Hellwig
2010-03-22 11:07 ` Christoph Hellwig
2010-03-22 11:33 ` Nick Piggin [this message]
2010-03-22 11:33 ` Nick Piggin
2010-03-22 11:55 ` Al Viro
2010-03-22 11:55 ` Al Viro
2010-03-22 12:26 ` Nick Piggin
2010-03-22 12:26 ` Nick Piggin
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=20100322113317.GK17637@laptop \
--to=npiggin@suse.de \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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.