From: Andrew Morton <akpm@osdl.org>
To: Muli Ben-Yehuda <mulix@mulix.org>
Cc: matthew@wil.cx, torvalds@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Make sure nobody's leaking resources
Date: Mon, 20 Mar 2006 13:34:07 -0800 [thread overview]
Message-ID: <20060320133407.1e75eafa.akpm@osdl.org> (raw)
In-Reply-To: <20060320161007.GA25444@granada.merseine.nu>
Muli Ben-Yehuda <mulix@mulix.org> wrote:
>
> On Mon, Mar 20, 2006 at 08:53:04AM -0700, Matthew Wilcox wrote:
> >
> > Currently, releasing a resource also releases all of its children. That
> > made sense when request_resource was the main method of dividing up the
> > memory map. With the increased use of insert_resource, it seems to me
> > that we should instead reparent the newly orphaned resources. Before
> > we do that, let's make sure that nobody's actually relying on the current
> > semantics.
> >
> > Signed-off-by: Matthew Wilcox <matthew@wil.cx>
> >
> > diff -urpNX dontdiff linus-2.6/kernel/resource.c parisc-2.6/kernel/resource.c
> > --- linus-2.6/kernel/resource.c 2006-03-20 07:29:06.000000000 -0700
> > +++ parisc-2.6/kernel/resource.c 2006-03-20 07:00:47.000000000 -0700
> > @@ -181,6 +181,8 @@ static int __release_resource(struct res
> > {
> > struct resource *tmp, **p;
> >
> > + BUG_ON(old->child);
> > +
>
> Is this expressely forbidden at this stage, or just "not recommended"?
> if the latter, WARN_ON() might be more appropriate.
>
Yes, there's no way we can make changes like this to either -mm or to
mainline. Making people's perfectly-working kernels go splat helps neither
them nor us.
A WARN_ON() which shuts itself up after one or three invokations would be
appropriate here.
prev parent reply other threads:[~2006-03-20 21:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-20 15:53 [PATCH] Make sure nobody's leaking resources Matthew Wilcox
2006-03-20 16:10 ` Muli Ben-Yehuda
2006-03-20 21:34 ` Andrew Morton [this message]
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=20060320133407.1e75eafa.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=mulix@mulix.org \
--cc=torvalds@osdl.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.