Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1556021 > unrolled thread

Re: [PATCH v3 0/5] MIPS: Add per-cpu IRQ stack

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v3 0/5] MIPS: Add per-cpu IRQ stack "Jason A. Donenfeld" <Jason@zx2c4.com> - 2017-01-11 00:40 +0100
    Re: [PATCH v3 0/5] MIPS: Add per-cpu IRQ stack Ralf Baechle <ralf@linux-mips.org> - 2017-01-11 02:30 +0100
      Re: [PATCH v3 0/5] MIPS: Add per-cpu IRQ stack "Jason A. Donenfeld" <Jason@zx2c4.com> - 2017-01-12 00:40 +0100
        Re: [PATCH v3 0/5] MIPS: Add per-cpu IRQ stack James Hogan <james.hogan@imgtec.com> - 2017-01-13 11:00 +0100
          Re: [PATCH v3 0/5] MIPS: Add per-cpu IRQ stack Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-15 14:50 +0100
            Re: [PATCH v3 0/5] MIPS: Add per-cpu IRQ stack "Jason A. Donenfeld" <Jason@zx2c4.com> - 2017-01-15 15:20 +0100
              Re: [PATCH v3 0/5] MIPS: Add per-cpu IRQ stack Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-15 15:40 +0100
                Re: [PATCH v3 0/5] MIPS: Add per-cpu IRQ stack "Jason A. Donenfeld" <Jason@zx2c4.com> - 2017-01-15 19:10 +0100
            Re: [PATCH v3 0/5] MIPS: Add per-cpu IRQ stack "Jason A. Donenfeld" <Jason@zx2c4.com> - 2017-01-15 15:20 +0100
          Re: [PATCH v3 0/5] MIPS: Add per-cpu IRQ stack "Jason A. Donenfeld" <Jason@zx2c4.com> - 2017-01-15 14:50 +0100

#1556021 — Re: [PATCH v3 0/5] MIPS: Add per-cpu IRQ stack

Was this ever picked up for 4.10 or 4.11?

[toc] | [next] | [standalone]

#1556126

On Wed, Jan 11, 2017 at 12:32:38AM +0100, Jason A. Donenfeld wrote:

> Was this ever picked up for 4.10 or 4.11?

Still sitting in -next as commit 3cc3434fd630 and its four parent commits.

  Ralf

[toc] | [prev] | [next] | [standalone]

#1557014

On Wed, Jan 11, 2017 at 2:20 AM, Ralf Baechle <ralf@linux-mips.org> wrote:
> On Wed, Jan 11, 2017 at 12:32:38AM +0100, Jason A. Donenfeld wrote:
>
>> Was this ever picked up for 4.10 or 4.11?
>
> Still sitting in -next as commit 3cc3434fd630 and its four parent commits.

Oh, good, so it's progressing normally. I just didn't see any
acknowledgement on this thread so I was worried.

Can this propagate to stable? A few OpenWRT MIPS people are
complaining to me about sporadic crashes when stacking too many
virtual network drivers (batman over gre over ppp over ...), which is
solved by this patchset.

Jason

[toc] | [prev] | [next] | [standalone]

#1558173

[Multipart message — attachments visible in raw view] — view raw

On Thu, Jan 12, 2017 at 12:32:52AM +0100, Jason A. Donenfeld wrote:
> On Wed, Jan 11, 2017 at 2:20 AM, Ralf Baechle <ralf@linux-mips.org> wrote:
> > On Wed, Jan 11, 2017 at 12:32:38AM +0100, Jason A. Donenfeld wrote:
> >
> >> Was this ever picked up for 4.10 or 4.11?
> >
> > Still sitting in -next as commit 3cc3434fd630 and its four parent commits.
> 
> Oh, good, so it's progressing normally. I just didn't see any
> acknowledgement on this thread so I was worried.
> 
> Can this propagate to stable? A few OpenWRT MIPS people are
> complaining to me about sporadic crashes when stacking too many
> virtual network drivers (batman over gre over ppp over ...), which is
> solved by this patchset.
> 
> Jason

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.

The actual stable kernel rules are here though:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/stable-kernel-rules.rst

Do the OpenWRT issues affect mainline kernels? (if its due to excessive
stack frame sizes in out of tree code, then that should be fixed out of
tree). It sounds bad if the kernel stack requirement can be made
arbitrarily large by stacking too many drivers.

Is there a simpler fix/workaround for the issue that would satisfy
stable kernel users until they can upgrade to a kernel with irqstacks?

Cheers
James

[toc] | [prev] | [next] | [standalone]

#1559233

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

[toc] | [prev] | [next] | [standalone]

#1559242

On Sun, Jan 15, 2017 at 3:11 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> According to Ralf, it's queued up for 4.11? Is that right?

It's in -next:

Part 1: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=fe8bd18ffea5327344d4ec2bf11f47951212abd0
Part 2: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=d42d8d106b0275b027c1e8992c42aecf933436ea
Part 3: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=510d86362a27577f5ee23f46cfb354ad49731e61
Part 4: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=dda45f701c9d7ad4ac0bb446e3a96f6df9a468d9
Part 5: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=3cc3434fd6307d06b53b98ce83e76bf9807689b9

[toc] | [prev] | [next] | [standalone]

#1559244

On Sun, Jan 15, 2017 at 03:15:35PM +0100, Jason A. Donenfeld wrote:
> On Sun, Jan 15, 2017 at 3:11 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> > According to Ralf, it's queued up for 4.11? Is that right?
> 
> It's in -next:
> 
> Part 1: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=fe8bd18ffea5327344d4ec2bf11f47951212abd0
> Part 2: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=d42d8d106b0275b027c1e8992c42aecf933436ea
> Part 3: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=510d86362a27577f5ee23f46cfb354ad49731e61
> Part 4: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=dda45f701c9d7ad4ac0bb446e3a96f6df9a468d9
> Part 5: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=3cc3434fd6307d06b53b98ce83e76bf9807689b9

Sweet, that's it?  Nice stuff, and all small and well-contained.

If the MIPS maintainers have no issue with this, and it works out well
in 4.11 for people (let's get it shaken out there first), I would have
no objection to backporting this to the 4.4 and 4.9 stable trees if it
will help out with issues that people are having with those tree.

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1559317

FYI, LEDE/OpenWRT is shipping this patchset now:
https://github.com/lede-project/source/commit/1708644f1915eb7587a904d81da0ef0b559d1567

[toc] | [prev] | [next] | [standalone]

#1559243

Hi Greg,

On Sun, Jan 15, 2017 at 2:48 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> How many patches is the irqstacks "feature" for MIPS?  What kernel was
> it released in?  Have any git commit ids I can look at?

According to Ralf, it's queued up for 4.11? Is that right?

Part 1: https://lkml.org/lkml/2016/12/19/250
Part 2: https://lkml.org/lkml/2016/12/19/251
Part 3: https://lkml.org/lkml/2016/12/19/252
Part 4: https://lkml.org/lkml/2016/12/19/254
Part 5: https://lkml.org/lkml/2016/12/19/248

Jason

[toc] | [prev] | [next] | [standalone]

#1559234

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.

Jason

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web