Well, the discussion is not quite on-topic, as the thread was about
shooting off kernel-sourcecode packages w/o any notice once again. But
anyway, you seem to be more interested in justifying 4KSTACKS
enforcement policies, so here we go.
On Sun, Aug 22, 2004 at 07:23:02PM +0200, Arjan van de Ven wrote:
> On Sun, 2004-08-22 at 16:24, Axel Thimm wrote:
>
> > Thanks for clarifying this, I thought 4KSTACKS was for making it
> > impossible to run XFS filesystems w/o risiking corruption. Oh, yes, I
> > forget XFS/reiserfs is not supported.
>
> actually you make XFS-vs-4Kstacks sound really horrible. On lkml there
> is some discussion by people who see problems, however in general these
> people are using a much older gcc which seems to have more stack "bloat"
> than the newer gcc we use. In addition, the regparm optimisation we use
> also reduces stack use somewhat.
It doesn't sound horrible, it simply is. Pick FC3t1/i386 and
NFS-export an almost full XFS fs. Then stress it over the network and
you get reproducable corruption. If that is not horrible, what is?
(P.S. x86_64 seems to cope better than i386 in this scenario)
> > Enforcing your policy by removing _the option_ to go back is
>
> Andrew Morton asked me for a patch to remove the option at the time 4K
> stacks got merged. Ideally there shouldn't be a choice, I mean,
I don't buy that, what benefit do you have to forbid choosing in
custom kernels to use what vanilla kernels still offer today? When
4KSTACKS gets its bugs ironed out, throw the switching code away, but
doing so while 4KSTACKS shows that it is far from mature in the kernel
itself (not talking of external kernel modules, I'm talking of
NFS/XFS), is asking for trouble.
And it really is the wrong way to enforce your policies. You already
have the default kernel for shaking out experimental features (nothing
against that, it's fedora's charter after all), whoever wants to build
a custom kernel has his reasons, don't deprive him of his choices.
> > bad politics, especially when at the same time lkml discussed whether
> > CONFIG_4KSTACKS should depend on CONFIG_BROKEN. What is there to gain
> > by removing the option? Very wrong educational skills IMHO.
>
> The patch has not gone into mainline yet because people still use the
> older gcc's. That's most of what is stopping it right now. However with
> the patches we add, non-4kstacks doesnt' seem to work (4g/4g for
> example,
That's a very bad example, because it only does not work, because you
yourself have removed the 8KSTACKs compatible hooks from the original
patch, the "empty space" is clearly visible in the patch and easily
rectifiable for the one that knows the original patch. If I were
paranoic I'd see an attempt of sabotaging non-4KSTACKs kernels
here. Here is the respective microsurgery that made 4g4g incompatible
to non-4KSTACKS ...
Original:
#define ARCH_MIN_TASKALIGN 16
+#ifdef CONFIG_4KSTACKS
+#define STACK_PAGE_COUNT (4096/PAGE_SIZE)
+#else
+#define STACK_PAGE_COUNT (8192/PAGE_SIZE)
+#endif
+
struct thread_struct {
Arjan:
#define ARCH_MIN_TASKALIGN 16
+
+#define STACK_PAGE_COUNT (4096/PAGE_SIZE)
+
+
+
+
struct thread_struct {
--
Axel.Thimm at ATrpms.net
Attachment:
pgpvnUT6j5D2e.pgp
Description: PGP signature
