From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: James Hogan <james.hogan@imgtec.com>,
Ralf Baechle <ralf@linux-mips.org>,
Matt Redfearn <matt.redfearn@imgtec.com>,
linux-mips@linux-mips.org, Thomas Gleixner <tglx@linutronix.de>,
Paolo Bonzini <pbonzini@redhat.com>,
Marcin Nowakowski <marcin.nowakowski@imgtec.com>,
Chris Metcalf <cmetcalf@mellanox.com>,
Petr Mladek <pmladek@suse.com>,
LKML <linux-kernel@vger.kernel.org>,
Adam Buchbinder <adam.buchbinder@gmail.com>,
Paul Burton <paul.burton@imgtec.com>, Jiri Slaby <jslaby@suse.cz>,
"Maciej W. Rozycki" <macro@imgtec.com>,
Aaron Tomlin <atomlin@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH v3 0/5] MIPS: Add per-cpu IRQ stack
Date: Sun, 15 Jan 2017 14:48:48 +0100 [thread overview]
Message-ID: <20170115134848.GA27658@kroah.com> (raw)
In-Reply-To: <CAHmME9oG65MFwT=5m8uaeLw8uf5kS8nC9oBBLf9_v11bTsiAsg@mail.gmail.com>
On Sun, Jan 15, 2017 at 02:39:49PM +0100, Jason A. Donenfeld wrote:
> Hi James,
>
> On Fri, Jan 13, 2017 at 10:49 AM, James Hogan <james.hogan@imgtec.com> wrote:
> > Its quite a significant change/feature, especially in terms of potential
> > for further breakage. I don't think its really stable material to be
> > honest. It sounds bad if the kernel stack requirement can be made
> > arbitrarily large by stacking too many drivers.
>
> Indeed I believe this is the case. If, say, a kthread is already using
> a bit of stack, and then a softirq chain of stacked virtual network
> drivers is called, the stack can be busted.
>
> > Is there a simpler fix/workaround for the issue that would satisfy
> > stable kernel users until they can upgrade to a kernel with irqstacks?
>
> The simplest solution is probably just not stacking tons of network
> drivers. For my own out-of-tree curve25519-donna code that's in
> OpenWRT and uses a fair amount of stack, I just kmalloc on MIPS but
> not on x86, so in terms of my own stuff there's already a workaround
> in place. But this still doesn't solve things for users who have some
> interesting networking requirements and stack a few drivers.
>
> Unfortunately, most folks are only testing stuff on ARM and x86, which
> already have the separate IRQ stacks, so they aren't hitting crashes.
>
> So, in the end, I'm not quite sure. On the one hand, this fixes an
> actual problem and it'd be nice to see stable kernels have the fix. On
> the other hand, this is a rather big change. I don't know how to
> assess it, but I've copied Greg on this email, who certainly has
> better judgement about this than me.
How many patches is the irqstacks "feature" for MIPS? What kernel was
it released in? Have any git commit ids I can look at?
thanks,
greg k-h
next prev parent reply other threads:[~2017-01-15 13:48 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-19 14:20 [PATCH v3 0/5] MIPS: Add per-cpu IRQ stack Matt Redfearn
2016-12-19 14:20 ` [PATCH v3 1/5] MIPS: Introduce irq_stack Matt Redfearn
2016-12-19 14:20 ` [PATCH v3 2/5] MIPS: Stack unwinding while on IRQ stack Matt Redfearn
2016-12-19 14:20 ` [PATCH v3 3/5] MIPS: Only change $28 to thread_info if coming from user mode Matt Redfearn
2016-12-21 12:13 ` Maciej W. Rozycki
2016-12-19 14:20 ` [PATCH v3 4/5] MIPS: Switch to the irq_stack in interrupts Matt Redfearn
2016-12-19 14:21 ` [PATCH v3 5/5] MIPS: Select HAVE_IRQ_EXIT_ON_IRQ_STACK Matt Redfearn
2016-12-21 1:18 ` [PATCH v3 0/5] MIPS: Add per-cpu IRQ stack Jason A. Donenfeld
2017-01-10 23:32 ` Jason A. Donenfeld
2017-01-11 1:20 ` Ralf Baechle
2017-01-11 23:32 ` Jason A. Donenfeld
2017-01-13 9:49 ` James Hogan
2017-01-15 13:39 ` Jason A. Donenfeld
2017-01-15 13:48 ` Greg Kroah-Hartman [this message]
2017-01-15 14:11 ` Jason A. Donenfeld
2017-01-15 14:15 ` Jason A. Donenfeld
2017-01-15 14:30 ` Greg Kroah-Hartman
2017-01-15 18:07 ` Jason A. Donenfeld
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=20170115134848.GA27658@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=Jason@zx2c4.com \
--cc=adam.buchbinder@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=atomlin@redhat.com \
--cc=cmetcalf@mellanox.com \
--cc=james.hogan@imgtec.com \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=macro@imgtec.com \
--cc=marcin.nowakowski@imgtec.com \
--cc=matt.redfearn@imgtec.com \
--cc=paul.burton@imgtec.com \
--cc=pbonzini@redhat.com \
--cc=pmladek@suse.com \
--cc=ralf@linux-mips.org \
--cc=tglx@linutronix.de \
/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