Hi!
> > (2) Make the architecture a configuration variable (!)
>
> Why?
>
> You still need to have all the damn cross-compilers etc. At which point
> being a configuration variable is the _least_ of your worries. You're
> better off with just a new tree.
Crosscompilers are easy: take pre-compi
Martin Dalecki <[EMAIL PROTECTED]> writes:
> There is some facility allowing to implement this kind of things
> in the C++ part of the most recent EGCS version which makes implementing
> such things "relatively" easy - basiclly there is the provision to dump
> the parser trees as easy to process
On Thu, 7 Sep 2000 19:14:26 -0500,
Michael Elizabeth Chastain <[EMAIL PROTECTED]> wrote:
>> Yeah. Long transition, plus user education (which never works, dontcha
>> know), plus probably a helper tool akin to checkconfig.
>
>I think it would help to have a well documented "module writers kit".
>
> Yeah. Long transition, plus user education (which never works, dontcha
> know), plus probably a helper tool akin to checkconfig.
I think it would help to have a well documented "module writers kit".
(Maybe there is one and I'm not aware of it).
mec> I'm all in favor of 'if ( CONFIG_BAR )', bu
[mec]
> In the .config file, the problem is that the Makefiles source .config
> and then do a lot of "ifdef CONFIG_FOO" tests. There are about 300
> instances of this in 2.4.0-test-7.
Separate issue. We're not talking about emitting n symbols to .config,
or at least I'm not. In this thread.
In the .config file, the problem is that the Makefiles source .config and
then do a lot of "ifdef CONFIG_FOO" tests. There are about 300 instances
of this in 2.4.0-test-7.
In include/linux/autoconf.h, the problem is in the *.c (and *.h and *.S)
files that do a lot of "#ifdef CONFIG_BAR" and "#if
If you want to look at an existing source-code analyzer that works
hand-in-glove with compilers, to skim for good or bad ideas, take a look
at the LSE/SCA combo from the DECset tools. (Dunno if DECset is even
still available; I lost track of what went where as they were dicing up
the company.)
-
David Woodhouse wrote:
> But how much work would it require to do so? If your theoretical vendor of
> closed-source compiler backends were to believe that a shared lib of the
> GCC frontend would be legal, surely they'd just make it shared themselves,
> then use it as such? It's hardly a effect
[viro]
> The _real_ problem is preprocessor abuse. BTW, could we schedule for
> 2.5 the following?
> * things like CONFIG_FOO are _always_ defined. As 0 or 1, that is.
> * #ifdef CONFIG_FOO => if (CONFIG_FOO) in *.c. gcc will kill the unused
> branches just fine.
Notwithstandin
[viro]
> > making the internal API frozen by exposure to library users.
[Gooch]
> An exercise in decent API design. BFD.
^^^
Nah, that's the *de*compilation library.
(Sorry, couldn't resist.)
Peter
-
To unsubscribe from this list: send the line "unsubscrib
[EMAIL PROTECTED] said:
> Shared library linkage brings you into the same grey area that binary
> only kernel modules fall into, this means it's risky and this is
> almost certainly how the GCC team views this situation.
But how much work would it require to do so? If your theoretical vendor o
Michael Elizabeth Chastain <[EMAIL PROTECTED]> wrote:
> We could use some more infrastructure here.
> (1) A 'make randomconfig' tool that generates a random configuration.
mconfig -m random, it's even written by you ;)
my current mconfig working version is on
ftp.openlinux.org/pub/people/hch/mc
Michael Elizabeth Chastain wrote:
> (c) With separate source and build trees, which I've implemented,
> it becomes a lot more feaasible to manage kernel builds for
> multiple platforms.
Is this released? I build most of my kernels for both x86 and PowerPC,
plus I build several configurat
Date: Wed, 6 Sep 2000 14:42:17 -0700 (PDT)
From: Jonathan Walther <[EMAIL PROTECTED]>
If the shared library is under GPL (not LGPL) that isn't a
problem. No?
Shared library linkage brings you into the same grey area that binary
only kernel modules fall into, this means it's risky an
-BEGIN PGP SIGNED MESSAGE-
If the shared library is under GPL (not LGPL) that
isn't a problem. No?
On Wed, 6 Sep 2000, David S. Miller wrote:
> Because this allows proprietary software vendor X to write
> closed-source compiler backend Y using GCC to provide the
> front end. If it neve
Martin MaD Douda writes:
> On Tue, 5 Sep 2000, Alexander Viro wrote:
> > The _real_ problem is preprocessor abuse. BTW, could we schedule for
> > 2.5 the following?
> > * things like CONFIG_FOO are _always_ defined. As 0 or 1, that is.
> > * #ifdef CONFIG_FOO => if (CONFIG_FOO) in *.c.
Date:Wed, 6 Sep 2000 08:59:56 -0600
From: Richard Gooch <[EMAIL PROTECTED]>
Jamie Lokier writes:
> Sorry, there's a GCC policy decision against putting it into a
> shared library.
Why?
Because this allows proprietary software vendor X to write
closed-source compiler ba
[EMAIL PROTECTED] (Arjan van de Ven) said:
[...]
> This is technically not true. I can cross-compile with my tools just fine,
> it "just" requires a decent cross-compiler on my system[1] [2].
That helps weeding out non-compile combinations. The _real_ fun ones are
those which boot and eat your
Alexander Viro wrote:
>
> On Wed, 6 Sep 2000, Martin Dalecki wrote:
>
> >
> > So may I just suggest to repleace the usage of cpp at all with something
> > more
> > suitable for the task at hand and with a much more regular/stringent
> > syntax
> > better fitting into the syntax of the pure C la
In article <[EMAIL PROTECTED]> you wrote:
> Linus writes ...
> mec> (2) Make the architecture a configuration variable (!)
> linus> Why?
> The real reason is that it's the right thing to do. Part of a
> configuration is "what machine it's for".
> Here are some benefits:
> (a) Arjan's testing
On Wed, 6 Sep 2000, Alexander Viro wrote:
>
> Add "and that broken code gets fixed in utterly bogus ways 20 versions
> down the road, when nobody remembers WTF had happened". Repeat several
> times (and rarely-used parts _will_ accumulate such crap) and you've got
> Lovecraftian beasts lurking
On Wed, 6 Sep 2000, Martin Dalecki wrote:
>
> So may I just suggest to repleace the usage of cpp at all with something
> more
> suitable for the task at hand and with a much more regular/stringent
> syntax
> better fitting into the syntax of the pure C language like m4 for
> example?
>
No. S
On Wed, 6 Sep 2000, Alexander Viro wrote:
>
>
> On 6 Sep 2000, Linus Torvalds wrote:
>
> > However, what I think Al Viro dislikes about this is that it does tend
> > to leave code that won't compile, just because some of the accesses are
> > in places that the compiler doesn't see due to the
Alexander Viro wrote:
>
> On Wed, 6 Sep 2000, Michael Elizabeth Chastain wrote:
>
> > We could use some more infrastructure here.
> >
> > (1) A 'make randomconfig' tool that generates a random configuration.
> >
> > (2) Make the architecture a configuration variable (!)
> >
> > (3) A collection
Linus writes ...
mec> (2) Make the architecture a configuration variable (!)
linus> Why?
The real reason is that it's the right thing to do. Part of a
configuration is "what machine it's for".
Here are some benefits:
(a) Arjan's testing machinery would catch problems in all architectures,
r
> (0) knowledge that CONFIG.FOO15 doesn't affect anything other than set of
> source files being compiled.
The Makefiles already know this. Specifically, mkdep.c analyzes which
C files depend on which options. Look at some of your .depend files.
Michael
-
To unsubscribe from this list: send
On 6 Sep 2000, Linus Torvalds wrote:
> However, what I think Al Viro dislikes about this is that it does tend
> to leave code that won't compile, just because some of the accesses are
> in places that the compiler doesn't see due to the pre-processor (or due
> to other build-rules: like in arch
On Wed, 6 Sep 2000, Michael Elizabeth Chastain wrote:
>
> We could use some more infrastructure here.
>
> (1) A 'make randomconfig' tool that generates a random configuration.
There already are people that do this.
The problem is that developers are lazy. All good programmers are lazy.
They w
On Wed, 6 Sep 2000, Michael Elizabeth Chastain wrote:
> We could use some more infrastructure here.
>
> (1) A 'make randomconfig' tool that generates a random configuration.
>
> (2) Make the architecture a configuration variable (!)
>
> (3) A collection of RPM's so that people can download a
On 6 Sep 2000, Linus Torvalds wrote:
> At the same time, there is no question that true #ifdef's have
> advantages, even outside the issue of gcc's inability to forget literal
> strings. They are often required for data structures in general: C does
> not have "conditional data structures". C
We could use some more infrastructure here.
(1) A 'make randomconfig' tool that generates a random configuration.
(2) Make the architecture a configuration variable (!)
(3) A collection of RPM's so that people can download and install
all the cross tools easily.
With this stuff available,
In article <8p5u21$r0$[EMAIL PROTECTED]> you wrote:
> However, what I think Al Viro dislikes about this is that it does tend
> to leave code that won't compile, just because some of the accesses are
> in places that the compiler doesn't see due to the pre-processor (or due
> to other build-rules:
In article <[EMAIL PROTECTED]>,
Jamie Lokier <[EMAIL PROTECTED]> wrote:
>Linus Torvalds wrote:
>> And I'm saying that if people really want to do this, then use the
>> computer to do it for you, having more than just "grep", and making your
>> tools aware of it.
>
>I'd just like to add, for the b
In article <[EMAIL PROTECTED]>,
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
>But still, doing the conditional compilation at compile-time rather than
>preprocessing-time is so *nice* that if you don't have too many literal
>strings floating about it may be justifiable.
>
>In cs89x0.c you reduce th
Alexander Viro writes:
>
>
>
> On Wed, 6 Sep 2000, Richard Gooch wrote:
>
> > Jamie Lokier writes:
> > > Chris Wedgwood wrote:
> > > > I think would be really cool if all this 'magic' in gcc (whatever
> > > > part of gcc is irrelevant right now) would be exported into a library
> > > > or shar
On Wed, 6 Sep 2000, Richard Gooch wrote:
> Jamie Lokier writes:
> > Chris Wedgwood wrote:
> > > I think would be really cool if all this 'magic' in gcc (whatever
> > > part of gcc is irrelevant right now) would be exported into a library
> > > or shared object which editors could then load and
On Wed, 6 Sep 2000, Martin MaD Douda wrote:
> Problem: every bloody line will go through the parser. There is too many
> lines. Compilation is realy slow today. I'm affraid this approach would
> make it worse. Note that 2.4.0-test7 has more than 2.75 milion lines.
> Or did you mean drivers wil
On Wed, 6 Sep 2000, Alan Cox wrote:
> > As readability - it's definitely at least as readable as
> > #if[def]. It also provides more consistent syntax. And when you are
> > using ifdef to violate scoping - your code is in need of rewrite anyway.
>
> You still need the #ifdef stuff as well
Jamie Lokier writes:
> Chris Wedgwood wrote:
> > I think would be really cool if all this 'magic' in gcc (whatever
> > part of gcc is irrelevant right now) would be exported into a library
> > or shared object which editors could then load and use... dynamically
> > perhaps.
>
> Sorry, there's a
On Tue, 5 Sep 2000, Alexander Viro wrote:
>
> The _real_ problem is preprocessor abuse. BTW, could we schedule for
> 2.5 the following?
> * things like CONFIG_FOO are _always_ defined. As 0 or 1, that is.
> * #ifdef CONFIG_FOO => if (CONFIG_FOO) in *.c. gcc will kill the unused
Chris Wedgwood wrote:
> I think would be really cool if all this 'magic' in gcc (whatever
> part of gcc is irrelevant right now) would be exported into a library
> or shared object which editors could then load and use... dynamically
> perhaps.
Sorry, there's a GCC policy decision against putting
Linus Torvalds wrote:
> And I'm saying that if people really want to do this, then use the
> computer to do it for you, having more than just "grep", and making your
> tools aware of it.
I'd just like to add, for the benefit of onlookers, that this is
quite easy.
Temporarily change name of `coun
Chris Wedgwood wrote:
[Gcc not eliminating trivial dead code...
did you compile without optimisation?]
Gcc 2.96 does remove the unreached code in your example,
but it still emits string constants.
int func()
{
if (1)
a = "foo";
else
a = "bar";
}
.LC0:
.string "foo"
.LC1:
On Wed, Sep 06, 2000 at 01:28:45PM +1200, Chris Wedgwood wrote:
> else
> a = 5;
> 10: c7 05 00 00 00 00 05movl $0x5,0x0
In current GCC, this is optimised away even at -O0, because it's
generally quicker to do dead code elimination than to emit the dead
code at all.
T
> As readability - it's definitely at least as readable as
> #if[def]. It also provides more consistent syntax. And when you are
> using ifdef to violate scoping - your code is in need of rewrite anyway.
You still need the #ifdef stuff as well for half of it so I dont see what
it buys you
[EMAIL PROTECTED] (Martin Dalecki) wrote on 06.09.00 in
<[EMAIL PROTECTED]>:
> Alexander Viro wrote:
> >
> > On Wed, 6 Sep 2000, Martin Dalecki wrote:
> >
> > > Easy - the same way you do for cross compilation. Basically just:
> > >
> > > export CC=g++ --some-magic-long-option-i-dont-remember;
Richard Gooch wrote:
>
> It will probably take about 5 years after a new version of GCC which
> has this fix before we can trust it to produce correct code for the
> kernel.
I don't think it's that bad, Richard. As davem points out, the dead
code elimination works OK. Chris has a counter-examp
On Wed, 6 Sep 2000, Martin Dalecki wrote:
>Basically I will just guess: The next maybe non free version of
>source navigator will use the mechanism I have just described above.
>So maybe there is already someone at RedHat doing exactly this work
>already ;-).
Source Navigator is GPL open source
Alexander Viro writes:
>
>
>
> On Wed, 6 Sep 2000, Andrew Morton wrote:
>
> > > cat t.c
> > foo()
> > {
> > if (0)
> > bar("hhh");
> > }
> > > gcc -O2 -c t.c
> > > strings t.o | grep hhh
> > hhh
Nasty, eh?
> Eww... Do they _ever_ remove dead code?
I guess not
Date:Tue, 5 Sep 2000 21:32:45 -0400 (EDT)
From: Alexander Viro <[EMAIL PROTECTED]>
On Wed, 6 Sep 2000, Andrew Morton wrote:
> > gcc -O2 -c t.c
> > strings t.o | grep hhh
> hhh
Eww... Do they _ever_ remove dead code?
They remove the code, they just forget to mar
On Wed, 6 Sep 2000, Andrew Morton wrote:
> > cat t.c
> foo()
> {
> if (0)
> bar("hhh");
> }
> > gcc -O2 -c t.c
> > strings t.o | grep hhh
> hhh
Eww... Do they _ever_ remove dead code?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Alexander Viro wrote:
>
>
> if (CONFIG_FOO) {
>
> } else {
>
> }
There are a zillion reasons why this technique is superior
to using `#ifdef CONFIG_FOO'. But, alas, gcc fumbles
the ball:
> cat t.c
foo()
{
if (0)
On Wed, 6 Sep 2000, Chris Wedgwood wrote:
> Oh, yes there is.
>
> if (CONFIG_FOO) {
>
> } else {
>
> }
>
> gcc can optimize that away and parser will see the whole thing.
>
> I'm not sure I like this construct either.
On Wed, 6 Sep 2000, Martin Dalecki wrote:
> Alexander Viro wrote:
> >
> > On Wed, 6 Sep 2000, Martin Dalecki wrote:
> >
> > > Easy - the same way you do for cross compilation. Basically just:
> > >
> > > export CC=g++ --some-magic-long-option-i-dont-remember; make
> >
> > ... and you still
Alexander Viro wrote:
>
> On Wed, 6 Sep 2000, Martin Dalecki wrote:
>
> > Easy - the same way you do for cross compilation. Basically just:
> >
> > export CC=g++ --some-magic-long-option-i-dont-remember; make
>
> ... and you still have only a subset of the tree, simply because it is fed
> throu
On Wed, 6 Sep 2000, Martin Dalecki wrote:
> Easy - the same way you do for cross compilation. Basically just:
>
> export CC=g++ --some-magic-long-option-i-dont-remember; make
... and you still have only a subset of the tree, simply because it is fed
through cpp before it reaches the parser.
On Tue, Sep 05, 2000 at 07:19:11PM -0400, Peter Rival wrote:
> Linus Torvalds wrote:
>
> > On Wed, 6 Sep 2000, Chris Wedgwood wrote:
> > >
> > > There are several other structures that have the same problem; very
> > > generic sounding members. I wonder would a patch changing struct page
> > > to
Linus Torvalds wrote:
> On Wed, 6 Sep 2000, Chris Wedgwood wrote:
> >
> > There are several other structures that have the same problem; very
> > generic sounding members. I wonder would a patch changing struct page
> > to something like this be acceptable?
>
> No.
>
> What would be acceptable is
Alexander Viro wrote:
>
> On Wed, 6 Sep 2000, Martin Dalecki wrote:
>
> > There is some facility allowing to implement this kind of things
> > in the C++ part of the most recent EGCS version which makes implementing
> > such things "relatively" easy - basiclly there is the provision to dump
> >
On Wed, 6 Sep 2000, Martin Dalecki wrote:
> There is some facility allowing to implement this kind of things
> in the C++ part of the most recent EGCS version which makes implementing
> such things "relatively" easy - basiclly there is the provision to dump
> the parser trees as easy to process
Linus Torvalds wrote:
>
> On Tue, 5 Sep 2000, Alexander Viro wrote:
> > >
> > > What would be acceptable is something that understands C, and that can be
> > > used to follow these things. Like "tags".
> >
> > I don't like hungarian notation too, but tags is out of question,
> > unfortunate
On Wed, 6 Sep 2000, Chris Wedgwood wrote:
>
> There are several other structures that have the same problem; very
> generic sounding members. I wonder would a patch changing struct page
> to something like this be acceptable?
No.
What would be acceptable is something that understands C, and t
On Wed, 6 Sep 2000, Chris Wedgwood wrote:
> --- mm.h.orig Wed Sep 6 07:01:38 2000
> +++ mm.h Wed Sep 6 07:02:18 2000
> @@ -142,18 +142,18 @@
> * is used for linear searches (eg. clock algorithm scans).
> */
> typedef struct page {
[snip]
> - atomic_t count;
[snip]
On Tue, 5 Sep 2000, Alexander Viro wrote:
> >
> > What would be acceptable is something that understands C, and that can be
> > used to follow these things. Like "tags".
>
> I don't like hungarian notation too, but tags is out of question,
> unfortunately. Too much preprocessor abuse in
On Tue, 5 Sep 2000, Linus Torvalds wrote:
>
>
> On Wed, 6 Sep 2000, Chris Wedgwood wrote:
> >
> > There are several other structures that have the same problem; very
> > generic sounding members. I wonder would a patch changing struct page
> > to something like this be acceptable?
>
> No.
On Wed, 6 Sep 2000, Chris Wedgwood wrote:
> On Tue, Sep 05, 2000 at 04:15:29PM -0400, Alexander Viro wrote:
>
> 2.5 the following?
> * things like CONFIG_FOO are _always_ defined. As 0 or 1, that is.
> * #ifdef CONFIG_FOO => if (CONFIG_FOO) in *.c. gcc will kill the unused
>
On 9/3/00, 3:20:01 AM, Alexander Viro <[EMAIL PROTECTED]> wrote regarding
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM now?:
> On Sat, 2 Sep 2000, Linus Torvalds wrote:
> > Not at all. In fact, I'd prefer it that way, because this same thing is
Arjan van de Ven wrote:
>
> In article <[EMAIL PROTECTED]> you
>wrote:
>
> > Well, the bug seems to exactly using the page after a "free_page()". Which
> > is always a bug, but at least should be easy to fix.
>
> > I've considered making "free_page()" a macro something like
>
> > __free
In article <[EMAIL PROTECTED]> you wrote:
> Well, the bug seems to exactly using the page after a "free_page()". Which
> is always a bug, but at least should be easy to fix.
> I've considered making "free_page()" a macro something like
> __free_pge(x);
> x = NULL;
Maybe the trick e
On Mon, 4 Sep 2000, Jamie Lokier wrote:
> Alexander Viro wrote:
> > > *((unsigned long *)(&x)) = NULL;
> >
> > free_page(foo()) and we've got problems...
>
> Alan really meant
>
> *((unsigned long *)&(x)) = NULL;
>
> and screw you if it's not an lvalue.
There's a lot of places that
Alexander Viro wrote:
> > *((unsigned long *)(&x)) = NULL;
>
> free_page(foo()) and we've got problems...
Alan really meant
*((unsigned long *)&(x)) = NULL;
and screw you if it's not an lvalue.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Sun, 3 Sep 2000, Alan Cox wrote:
> > I've considered making "free_page()" a macro something like
> >
> > __free_pge(x);
> > x = NULL;
> >
> > but that works only for lvalues, of course, and not all users are
> > lvalue-users, so it's hard to do. But that would have caught this.
>
> I've considered making "free_page()" a macro something like
>
> __free_pge(x);
> x = NULL;
>
> but that works only for lvalues, of course, and not all users are
> lvalue-users, so it's hard to do. But that would have caught this.
Not that hard. (barf buckets at the ready)
On Sun, 3 Sep 2000, Rik van Riel wrote:
> On Sun, 3 Sep 2000, Linus Torvalds wrote:
> >
> > What you're saying is that you're ignoring the evidence because you don't
> > like it and you don't understand how it happens.
> >
> > The BUG() was "impossible", so you're discounting it?
> >
> > I c
On Sun, 3 Sep 2000, Linus Torvalds wrote:
> On Sun, 3 Sep 2000, Rik van Riel wrote:
> > > Rik.
> > >
> > > You're apparently completely ignoring the fact that the page
> > > "already on the LRU queue" was just allocated from
> > > __alloc_pages() in the backtrace you had.
> >
> > It wasn't. If i
On Sun, 3 Sep 2000, Rik van Riel wrote:
> > Rik.
> >
> > You're apparently completely ignoring the fact that the page
> > "already on the LRU queue" was just allocated from
> > __alloc_pages() in the backtrace you had.
>
> It wasn't. If it was allocated there, the boobytraps in
> either rmqueu
On Sun, 3 Sep 2000, Linus Torvalds wrote:
> On Sun, 3 Sep 2000, Rik van Riel wrote:
> > >
> > > I'd like to know what it was. Last I heard, it was still the
> > > case of "pages just off the freelist had some bits set that they
> > > shouldn't have". That makes me nervous.
> >
> > Nope, that was
On Sun, 3 Sep 2000, Rik van Riel wrote:
> >
> > I'd like to know what it was. Last I heard, it was still the
> > case of "pages just off the freelist had some bits set that they
> > shouldn't have". That makes me nervous.
>
> Nope, that was what you /thought/ it was.
Rik.
You're apparently c
On Sun, 3 Sep 2000, Rik van Riel wrote:
> On Sat, 2 Sep 2000, Linus Torvalds wrote:
> > On Sat, 2 Sep 2000, Rik van Riel wrote:
>
> > > 1) the innd data corruption bug
> >
> > This, I think, was due to a bug in ext2 truncate. If so, it
> > should be fixed in test8-pre2.
>
> Cool...
Unfortun
On Sat, 2 Sep 2000, Linus Torvalds wrote:
> On Sat, 2 Sep 2000, Rik van Riel wrote:
> > 1) the innd data corruption bug
>
> This, I think, was due to a bug in ext2 truncate. If so, it
> should be fixed in test8-pre2.
Cool...
> > 2) system hangs with 0 free low memory and some free
> >high
On Sun, 3 Sep 2000, Alexander Viro wrote:
> OK, after a bit of thinking it looks like we'll need slightly different
> prototype. How about the following? BTW, mem_is_zero() really asks for
> inclusion into string.h, IMO.
Arrgh. Sorry about that mess. Corrected variant:
diff -urN rc8-2/fs/buf
Hi !
I've read the discussion about the truncate() problem and tried to
understand ;) However, there's somethign I don't catch in your code (typo
? bug ? misunderstanding on my side ?)
Linus wrote:
There's a really simple way to avoid this: compare the thing you're going
to zero out against zer
On Sun, 3 Sep 2000, [iso-8859-1] Henrik Størner wrote:
> On Sat, Sep 02, 2000 at 01:58:58PM -0700, Linus Torvalds wrote:
>
> [ext2 truncate bug which caused the innd file corruption may
> also affect other filesystems]
>
> > Anyway, the way to test if you have the bug is this simple program
On Sat, Sep 02, 2000 at 01:58:58PM -0700, Linus Torvalds wrote:
[ext2 truncate bug which caused the innd file corruption may
also affect other filesystems]
> Anyway, the way to test if you have the bug is this simple program from
> Al Viro who noticed the bug and has the fix - notice that you n
On Sat, 2 Sep 2000, Linus Torvalds wrote:
> Not at all. In fact, I'd prefer it that way, because this same thing is
> obviously going to be useful for any other block filesystem with the same
> issue.
Which is a nice way to say "any other block filesystem in the tree" ;-/
Oh, well... Modulo ->
On Sat, 2 Sep 2000, Linus Torvalds wrote:
>
>
> On Sun, 3 Sep 2000, Alexander Viro wrote:
> > >
> > > Comments? Basically the "grab_cache_page()" would be a "read_cache_page()"
> > > instead with all the wait-on-page etc stuff.
> >
> > Works for me. However, that way it looks like a fs/buf
On Sun, 3 Sep 2000, Alexander Viro wrote:
> >
> > Comments? Basically the "grab_cache_page()" would be a "read_cache_page()"
> > instead with all the wait-on-page etc stuff.
>
> Works for me. However, that way it looks like a fs/buffer.c fodder.
> Mind if I just call it block_zero_page(page, f
On Sat, 2 Sep 2000, Linus Torvalds wrote:
> You don't actually have to be smart.
>
> There's a really simple way to avoid this: compare the thing you're going
> to zero out against zero before you memset() it to zero. If it was already
> zero, you just unlock the page and release.
>
> Downsi
On Sat, 2 Sep 2000, Alexander Viro wrote:
> +
> + /*
> + * So truncate in the middle of a hole not on a block boundary will
> + * allocate a block. BFD. Everything is still consistent, so trying
> + * to be smart is not worth the trouble.
> + */
You don't actually have t
On Sat, 2 Sep 2000, Alexander Viro wrote:
> IOW, bug in question _does_ give the same kind of behaviour, but whether
> innd is hitting it or something different that happens to act like that...
> The only way to know is to try it.
>
> I'll send rediffed patch in half an hour.
All right, it t
On Sat, Sep 02, 2000 at 12:56:07PM -0700, Linus Torvalds wrote:
> I'd like to know what it was. Last I heard, it was still the case of
> "pages just off the freelist had some bits set that they shouldn't have".
> That makes me nervous.
Perhaps this is an example of a problem that would be found
On Sat, 2 Sep 2000, Linus Torvalds wrote:
> > 1) the innd data corruption bug
>
> This, I think, was due to a bug in ext2 truncate. If so, it should be
> fixed in test8-pre2.
Ted had ACKed the previous chunk of truncate changes, so that one will go
immediately once the -pre2 is on ftp.kernel
In article <8ornsg$h70$[EMAIL PROTECTED]>,
Henrik =?ISO-8859-1?Q?St=F8rner?= <[EMAIL PROTECTED]> wrote:
>
>I am one of the people who have been seeing this problem. I would be
>very surprised if it was an ext2 problem, as the only ext2 filesystem
>on my disk contains all of /boot. No programs, no
In <[EMAIL PROTECTED]> Linus Torvalds
<[EMAIL PROTECTED]> writes:
>On Sat, 2 Sep 2000, Rik van Riel wrote:
>>
>> In fact, I plan to spend most of my time trying to track down
>> the 2 VM problems on tytso's list:
>>
>> 1) the innd data corruption bug
>This, I think, was due to a bug in ext2 t
On Sat, 2 Sep 2000, Rik van Riel wrote:
>
> In fact, I plan to spend most of my time trying to track down
> the 2 VM problems on tytso's list:
>
> 1) the innd data corruption bug
This, I think, was due to a bug in ext2 truncate. If so, it should be
fixed in test8-pre2.
Al, I think you said y
On Sat, 2 Sep 2000, Linus Torvalds wrote:
> On Sat, 2 Sep 2000, Rik van Riel wrote:
> >
> > Not really. I'm not aware of any bug with my VM that doesn't
> > occur in the standard VM too.
>
> So what happened with the BUG() thing that you had? I never saw
> any resolution to that, and that certai
On Sat, 2 Sep 2000, Rik van Riel wrote:
>
> Not really. I'm not aware of any bug with my VM that doesn't
> occur in the standard VM too.
So what happened with the BUG() thing that you had? I never saw any
resolution to that, and that certainly didn't happen with the standard VM.
On Sat, 2 Sep 2000, bert hubert wrote:
> On Fri, Sep 01, 2000 at 03:58:22PM -0300, Rik van Riel wrote:
>
> > > filesystem? It starts swapping like mad and generally behaves
> > > indecently, despite the huge 1024M of RAM it has.
> >
> > http://www.surriel.com/patches/2.4.0-t8p1-vmpatch2
> >
> >
On Fri, 1 Sep 2000, Rik van Riel wrote:
> On Fri, 1 Sep 2000, Chris Evans wrote:
> > On Fri, 1 Sep 2000, Rik van Riel wrote:
> > > On Fri, 1 Sep 2000, Tigran Aivazian wrote:
> > >
> > > > Any of you tried copying a 2G file in the same (ext2)
> > > > filesystem? It starts swapping like mad and ge
Hrm. very weird. I guess it doesn't do it anymore (couldn't tell you if it
did it on test8-pre1 w/o vmpatch, i had it disabled) - only when you abort
it in the middle. In any case, here's what /proc/slabinfo says:
slabinfo - version: 1.1
kmem_cache59 78100221
uhci_
1 - 100 of 106 matches
Mail list logo
