linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nick Piggin <npiggin@suse.de>
To: Andrew Morton <akpm@linux-foundation.org>,
	Pekka Enberg <penberg@cs.helsinki.fi>
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 21:40:57 +1100	[thread overview]
Message-ID: <20100322104057.GG17637@laptop> (raw)
In-Reply-To: <20100322005610.5dfa70b1.akpm@linux-foundation.org>

On Mon, Mar 22, 2010 at 12:56:10AM -0400, Andrew Morton wrote:
> On Mon, 22 Mar 2010 16:39:37 +1100 Nick Piggin <npiggin@suse.de> wrote:
> 
> > It's ugly and lazy that we do these default aops in case it has not
> > been filled in by the filesystem.
> > 
> > A NULL operation should always mean either: we don't support the
> > operation; we don't require any action; or a bug in the filesystem,
> > depending on the context.
> > 
> > In practice, if we get rid of these fallbacks, it will be clearer
> > what operations are used by a given address_space_operations struct,
> > reduce branches, reduce #if BLOCK ifdefs, and should allow us to get
> > rid of all the buffer_head knowledge from core mm and fs code.
> 
> I guess this is one way of waking people up.
> 
> What happens is that hundreds of bug reports land in my inbox and I get
> to route them to various maintainers, most of whom don't exist, so
> warnings keep on landing in my inbox.  Please send a mailing address for
> my invoices.

The Linux Foundation
1796 18th Street, Suite C
San Francisco, CA 94107

:)


> It would be more practical, more successful and quicker to hunt down
> the miscreants and send them rude emails.  Plus it would save you
> money.

I could do my best at the obvious (and easy to test filesystems) before
asking you to merge the warning patch. It's probably not totally trivial
to work out what aops are left NULL because they want the default
buffer-head helper, and which are left NULL because they aren't needed.
(this is one problem of having the default callback of course)


>
> > We could add a patch like this which spits out a recipe for how to fix
> > up filesystems and get them all converted quite easily.
> > 
> > ...
> >
> > @@ -40,8 +40,14 @@ void do_invalidatepage(struct page *page
> >  	void (*invalidatepage)(struct page *, unsigned long);
> >  	invalidatepage = page->mapping->a_ops->invalidatepage;
> >  #ifdef CONFIG_BLOCK
> > -	if (!invalidatepage)
> > +	if (!invalidatepage) {
> > +		static bool warned = false;
> > +		if (!warned) {
> > +			warned = true;
> > +			print_symbol("address_space_operations %s missing invalidatepage method. Use block_invalidatepage.\n", (unsigned long)page->mapping->a_ops);
> > +		}
> >  		invalidatepage = block_invalidatepage;
> > +	}
> 
> erk, I realise 80 cols can be a pain, but 165 cols is just out of
> bounds.  Why not
> 
> 	/* this fs should use block_invalidatepage() */
> 	WARN_ON_ONCE(!invalidatepage);

Problem is that it doesn't give you the aop name (and call trace
probably won't help). I'll make it all into a macro though.

  parent reply	other threads:[~2010-03-22 10:40 UTC|newest]

Thread overview: 13+ 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  4:56 ` Andrew Morton
2010-03-22  8:00   ` Pekka Enberg
2010-03-22 10:40   ` Nick Piggin [this message]
2010-03-22 13:30     ` Andrew Morton
2010-03-22 21:01       ` Nick Piggin
2010-03-22  9:17 ` Boaz Harrosh
2010-03-22 10:54   ` Nick Piggin
2010-03-22 12:05     ` Boaz Harrosh
2010-03-22 11:07 ` Christoph Hellwig
2010-03-22 11:33   ` Nick Piggin
2010-03-22 11:55 ` Al Viro
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=20100322104057.GG17637@laptop \
    --to=npiggin@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=penberg@cs.helsinki.fi \
    /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).