From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Andrew Morton <akpm@osdl.org>
Cc: Mike Waychison <mikew@google.com>,
linux-mm@kvack.org,
Linux Kernel list <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@osdl.org>
Subject: Re: [RFC] page fault retry with NOPAGE_RETRY
Date: Fri, 22 Sep 2006 09:09:25 +1000 [thread overview]
Message-ID: <1158880165.26347.132.camel@localhost.localdomain> (raw)
In-Reply-To: <20060921154105.904313f7.akpm@osdl.org>
On Thu, 2006-09-21 at 15:41 -0700, Andrew Morton wrote:
> On Fri, 22 Sep 2006 08:05:04 +1000
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > > So I think there's a nasty DoS here if we permit infinite retries. But
> > > it's not just that - there might be other situations under really heavy
> > > memory pressure where livelocks like this can occur. It's just a general
> > > robustness-of-implementation issue.
> >
> > Got it. Now, changing args to no_page() will be a pretty big task....
> >
>
> Not as big as removing the pt_regs arg from every interrupt handler ;)
Which is a change I'm not 100% convinced about btw ... I remember
actually using that in a few occasions... mostly for debugging though.
Bah, anyway, I suppose we can always have a per-cpu global with the last
irq pt_regs pointer if really needed for debug.
> But pretty mechanical. Problem is, I don't think we have our mechanic.
Yup, we would need to decide what to put in there....
Ben.
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Andrew Morton <akpm@osdl.org>
Cc: Mike Waychison <mikew@google.com>,
linux-mm@kvack.org,
Linux Kernel list <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@osdl.org>
Subject: Re: [RFC] page fault retry with NOPAGE_RETRY
Date: Fri, 22 Sep 2006 09:09:25 +1000 [thread overview]
Message-ID: <1158880165.26347.132.camel@localhost.localdomain> (raw)
In-Reply-To: <20060921154105.904313f7.akpm@osdl.org>
On Thu, 2006-09-21 at 15:41 -0700, Andrew Morton wrote:
> On Fri, 22 Sep 2006 08:05:04 +1000
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > > So I think there's a nasty DoS here if we permit infinite retries. But
> > > it's not just that - there might be other situations under really heavy
> > > memory pressure where livelocks like this can occur. It's just a general
> > > robustness-of-implementation issue.
> >
> > Got it. Now, changing args to no_page() will be a pretty big task....
> >
>
> Not as big as removing the pt_regs arg from every interrupt handler ;)
Which is a change I'm not 100% convinced about btw ... I remember
actually using that in a few occasions... mostly for debugging though.
Bah, anyway, I suppose we can always have a per-cpu global with the last
irq pt_regs pointer if really needed for debug.
> But pretty mechanical. Problem is, I don't think we have our mechanic.
Yup, we would need to decide what to put in there....
Ben.
--
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:[~2006-09-21 23:10 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-14 22:55 [RFC] page fault retry with NOPAGE_RETRY Benjamin Herrenschmidt
2006-09-14 22:55 ` Benjamin Herrenschmidt
2006-09-15 0:19 ` Linus Torvalds
2006-09-15 0:19 ` Linus Torvalds
2006-09-15 7:11 ` Andrew Morton
2006-09-15 7:11 ` Andrew Morton
2006-09-15 7:35 ` Andrew Morton
2006-09-15 7:35 ` Andrew Morton
2006-09-15 13:30 ` Hugh Dickins
2006-09-15 13:30 ` Hugh Dickins
2006-09-16 1:03 ` Benjamin Herrenschmidt
2006-09-16 1:03 ` Benjamin Herrenschmidt
2006-09-19 23:35 ` Mike Waychison
2006-09-19 23:50 ` Benjamin Herrenschmidt
2006-09-19 23:50 ` Benjamin Herrenschmidt
2006-09-19 23:59 ` Andrew Morton
2006-09-19 23:59 ` Andrew Morton
2006-09-20 0:06 ` Benjamin Herrenschmidt
2006-09-20 0:06 ` Benjamin Herrenschmidt
2006-09-20 0:05 ` Benjamin Herrenschmidt
2006-09-20 0:05 ` Benjamin Herrenschmidt
2006-09-20 0:21 ` Andrew Morton
2006-09-20 0:21 ` Andrew Morton
2006-09-20 1:57 ` Benjamin Herrenschmidt
2006-09-20 1:57 ` Benjamin Herrenschmidt
2006-09-20 3:05 ` Andrew Morton
2006-09-20 3:05 ` Andrew Morton
2006-09-20 5:04 ` Benjamin Herrenschmidt
2006-09-20 5:04 ` Benjamin Herrenschmidt
2006-09-20 5:26 ` Andrew Morton
2006-09-20 5:26 ` Andrew Morton
2006-09-20 6:54 ` Benjamin Herrenschmidt
2006-09-20 6:54 ` Benjamin Herrenschmidt
2006-09-20 17:53 ` Andrew Morton
2006-09-20 17:53 ` Andrew Morton
2006-09-21 22:05 ` Benjamin Herrenschmidt
2006-09-21 22:05 ` Benjamin Herrenschmidt
2006-09-21 22:41 ` Andrew Morton
2006-09-21 22:41 ` Andrew Morton
2006-09-21 23:09 ` Benjamin Herrenschmidt [this message]
2006-09-21 23:09 ` Benjamin Herrenschmidt
2006-09-23 14:21 ` Hugh Dickins
2006-09-23 14:21 ` Hugh Dickins
2006-09-23 19:46 ` Andrew Morton
2006-09-23 19:46 ` Andrew Morton
2006-09-23 22:35 ` Benjamin Herrenschmidt
2006-09-23 22:35 ` Benjamin Herrenschmidt
2006-09-20 5:06 ` Benjamin Herrenschmidt
2006-09-20 5:06 ` Benjamin Herrenschmidt
2006-09-20 1:14 ` Mike Waychison
2006-09-20 1:14 ` Mike Waychison
2006-09-20 2:02 ` Benjamin Herrenschmidt
2006-09-20 2:02 ` Benjamin Herrenschmidt
2006-09-15 21:35 ` Arnd Bergmann
2006-09-15 21:35 ` Arnd Bergmann
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=1158880165.26347.132.camel@localhost.localdomain \
--to=benh@kernel.crashing.org \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mikew@google.com \
--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.