[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wjqp09i1053vqFc41Ftegkrh0pD+MKY-3ptdYu3FUh6Bw@mail.gmail.com>
Date: Mon, 3 Jul 2023 09:49:50 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Helge Deller <deller@....de>
Cc: Guenter Roeck <linux@...ck-us.net>, stable@...r.kernel.org,
linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
linux-parisc <linux-parisc@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
John David Anglin <dave.anglin@...l.net>
Subject: Re: [PATCH 6.4 00/28] 6.4.1-rc1 review - hppa argument list too long
On Mon, 3 Jul 2023 at 00:08, Helge Deller <deller@....de> wrote:
>
> Great, that patch fixes it!
Yeah, I was pretty sure this was it, but it's good to have it
confirmed. Committed.
> I wonder if you want to
> #define VM_STACK_EARLY VM_GROWSDOWN
> even for the case where the stack grows down too (instead of 0),
> just to make clear that in both cases the stack goes downwards initially.
No, that wouldn't work for the simple reason that the special bits in
VM_STACK_INCOMPLETE_SETUP are always cleared after the stack setup is
done.
So if we added VM_GROWSDOWN to those early bits in general, the bit
would then be cleared even when that wasn't the intent.
Yes, yes, we could change the VM_STACK_INCOMPLETE_SETUP logic to only
clear some of the bits in the end, but the end result would be
practically the same: we'd still have to do different things for
grows-up vs grows-down cases, so the difference might as well be here
in the VM_STACK_EARLY bit.
Linus
Powered by blists - more mailing lists