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 that
This entry in the changelog says it all:
- truncate. Guess what? We threw away the key to the clue-box
Most of the other stuff is cleanups or reasonably straightforward fixes.
The truncate thread that's been going through the last few pre-releases is
the big thing, and the one that has
On Wed, 6 Sep 2000, Chris Wedgwood wrote:
On Tue, Sep 05, 2000 at 06:25:39PM -0300, Rik van Riel wrote:
I hope Linus will release an "emergency" 2.4.0-test8-pre5 really
soon, maybe even with /only/ Al Viro's two-line fix...
Ouch... I just got hit by this. At first I though it
On Wed, 6 Sep 2000, Udo A. Steinberg wrote:
I'm still experiencing ext2 corruption even with the newest patch
test8-pre5. I'm not using bugtraq, mutt or pine and I'm fairly sure
it's not caused by a badly written application or strange input.
Interesting oops.
Basically your
On Tue, 5 Sep 2000, Alexander Viro wrote:
How about reverting to compare-and-write-if-nonzero variant?
_That_ will be definitely legal.
Yes, but I would really hate to have the case that a (shortening) truncate
could fail due to disk-full issues.
I think that's just wrong (sure, I can see
How about this patch?
NOTE NOTE NOTE! I'm on my way home now to be a family man, so I've not
actually tested it AT ALL. You have been warned.
The basic approach should be ok, and it avoids using the write path at all
because it isn't actually needed. The truncate() case is, in the end, much
On Wed, 6 Sep 2000, Chris Mason wrote:
Ah, I was missing that __block_prepare_write and __block_write_fullpage
both set the end_io handler to end_io_sync. In one case, reiserfs is doing
i/o without properly setting the handler, which is why I was seeing bugs
caused by the above
On Wed, 6 Sep 2000, Tim Waugh wrote:
On Tue, Sep 05, 2000 at 07:14:02PM -0700, Linus Torvalds wrote:
How about this patch?
Got this oops.
This one I cannot explain.
It's a bh that is NULL, but it's a new case completely. It looks like you
have a 1kB blocksize, no? It furthermore looks
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 t
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 want
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 in
On Wed, 6 Sep 2000, Tigran Aivazian wrote:
very nice monologue, thanks. It would be great to know Linus' opinion. I
mean, I knew Linus' opinion of some years' ago but perhaps it changed? He
is a living being and not some set of rules written in stone so perhaps
current
In article [EMAIL PROTECTED],
Jeff V. Merkey [EMAIL PROTECTED] wrote:
Linus Torvalds wrote:
Apparently, if you follow the arguments, not having a kernel debugger
leads to various maladies:
- you crash when something goes wrong, and you fsck and it takes forever
and you get frustrated
On Wed, 6 Sep 2000, Daniel Phillips wrote:
Linus Torvalds wrote:
And quite frankly, for most of the real problems (as opposed to the stupid
bugs - of which there are many, as the latest crap with "truncate()" has
shown us) a debugger doesn't much help. And the real problems
On Wed, 6 Sep 2000, Marco Colombo wrote:
As you said, the are two kinds of reactions. I don't understand why you
think that the presence of a debugger will *prevent* people from doing
the Right Thing and "think about problems another way". Are debuggers so
evil? Will a KDB option in the
On Wed, 6 Sep 2000, Jeff V. Merkey wrote:
Think of rabbits. And think of how the wolf helps them in the end. Not
by being nice, no. But the rabbits breed, and they are better for having
to worry a bit.
You know those huge, sharp teeth on the wolf? Want to make them longer
and
On Wed, 6 Sep 2000, Alan Cox wrote:
What would a debugger have done?
Let the end user give me essential answers on what was happening at the failure
point. Think of it as a crash dump tool with extra controls
Sure. I just don't see many end-users single-stepping through interrupt
Yeah. Maybe we fixed truncate, and maybe we didn't. I've thought that we
fixed it now several times, and I was always wrong. Time for some reverse
phychology:
I'm sure this one doesn't fix the truncate bug either.
But I have this ugly feeling that I'm coming down with the same flu that
On Thu, 7 Sep 2000, Tigran Aivazian wrote:
k) all swapout functions in mm/vmscan.c can be optimized by removing 'mm'
argument. This part was reviewed by Rick van Riel and approved.
But they then get "mm" themselves anyway.
What's the point? With argument passing, on certain
In article [EMAIL PROTECTED],
Dave Allen [EMAIL PROTECTED] wrote:
My company is currently working on a linux network driver (I'm sorry,
but I can't disclose which company or the nature of the driver right
now). However, recent discussions on this list have made me grow
concerned about
On Sat, 9 Sep 2000, Jamie Lokier wrote:
I think an appropriate concern. The future GPL is constrained by the GPLv2
clause 9 to be 'similar in spirit...'. You also dont ever have to take any
code that specifies GPLv3 or later.
Linus, nobody can ever force GPLv3 upon you. If you don't
On Sat, 9 Sep 2000, David Weinehall wrote:
This patches changes the names of the init-functions for the
hamradio-drivers pt.c and pi2.c. None of the new names are used anywhere
else in the kernel.
Patch applied, but I also wonder why these things are global names anyway?
Why not just
On Sat, 9 Sep 2000, Oliver Xymoron wrote:
Tools are tools. They don't make better code. They make better code easier
if used properly.
I think you missed the point of my original reply completely.
The _technical_ side of the tool in question is completely secondary.
The social
On Sun, 10 Sep 2000, Alexander Viro wrote:
Arrggh. Linus, buffer can be up-to-date, but unmapped. Marking it dirty is
illegal, indeed. IOW, we need to (cut-and-paste alert)
Goopd catch. Yes, we should just do the mapped/uptodate checks in the
other order. Good call.
Linus
On Mon, 11 Sep 2000, Alan Cox wrote:
Both machines here (a desktop, P3/600 on an intel SR440BX motherboard,
running Red Hat 6.9.5; kernel compiled with kgcc (egcs-1.1.2); a notebook,
Toshiba Satellite pro 4280 XDVD or some such, mobile P3/500, running Red
Hat 6.2) hang after "OK, now
On Sat, 9 Sep 2000, Richard Henderson wrote:
There are two main purposes to this reorg:
* Split up the tremndously huge xor.c.
Looks ok, however:
- please use unified diffs. Standard context diffs are horrible.
- Please split this up the same way the checksums were split up:
make
On Wed, 13 Sep 2000, Andre Hedrick wrote:
Okay who can teach me how to force hooks and ram this down the PPC
pci_write_config_word(dev, PCI_COMMAND, 0x05);
If the PPC PCI code doesn't do this, then that's a PPC architecture bug.
DO NOT DO THIS IN THE DRIVER! Fix the real problem
On Fri, 15 Sep 2000, Gérard Roudier wrote:
Just as an example: imagine that the IO windows haven't been set up
correctly. If the low-level driver just blindly enables IO cycles by
writing to the PCI_COMMAND register, that device may come up in an invalid
state, and mess up the whole
On Wed, 13 Sep 2000, Andrew Morton wrote:
Finally some clarity with what is going on inside this Dell CPx650
laptop (TI PCI1225 Cardbus bridge). Yes, it _is_ contact bounce. It
seems to find the 3com NIC particularly offensive - the card can easily
bounce out 150 milliseconds after the
On Fri, 15 Sep 2000, David Hinds wrote:
socket-events = 0;
to "yenta_get_status()". Nothing more, nothing less.
I think this is a bad idea. Ignoring latched events and relying on
the current socket status is unsafe. You can ignore transient
card-detect events when the
Ok, the new MM balancing has been getting good reviews, and no longer has
any known issues. Integrated. We'd have needed to do it sooner or later
anyway (just see what happened in 2.2.x), the sooner we do it the less
traumatic it will end up being.
Oh, and yeah, there obviously was still a
On 16 Sep 2000, Trond Myklebust wrote:
Yes. fs/read_write calls the NFS subsystem. The problem then is that
NFS uses the generic_file_{read,write,mmap}() interfaces. These are
what enforce use of the page cache.
You could drop these functions, but that would mean designing an
entire
Ok. I think we're getting to the point where there are no major known
bugs. That means that as of the final 2.4.0-test9 I will no longer accept
any patches that don't have a critical problem (as defined by Teds list)
associated with them.
So when you send me a patch, either bug Ted to mark the
On Sun, 17 Sep 2000, Jan Niehusmann wrote:
Further investigation shows that this duplication is caused by the call
to scan_scsis in line 1565 of scsi.c, and this one can not be commented out
as it is needed.
But I have some problems understanding all the module/non-module stuff:
On Mon, 18 Sep 2000, Chris Wedgwood wrote:
On Sun, Sep 17, 2000 at 10:37:51AM -0700, Linus Torvalds wrote:
- "extern inline" - "static inline". It doesn't matter right now,
but it's proactive for future gcc versions.
can someone please explain th
On Sun, 17 Sep 2000, Marco d'Itri wrote:
I added to block_write_full_page() the debugging code suggested by
Alexander Viro:
if (inode-i_dev == 0x305 inode-i_ino == 48991) // Md
printk("block_write_full_page: writing page %d, size %Ld\n",
On Sun, 17 Sep 2000, Linus Torvalds wrote:
I bet your patch fixes the corruption, but I want to understand _why_.
Call me dense, but __block_commit_write() seems to do everything we want
done..
Ok, I may be dense, but I see the bug.
And no, your patch was not the right thing either
On Sun, 17 Sep 2000, Alexander Viro wrote:
Ugh. OK, first of all, patch is _not_ correct. Doesn't zero out the end of
partial block.
note to myself: no patches before the first cup of coffee
Yeah. See my other mail - I don't think the patch is needed at all,
although I'm convinced that it
On Sun, 17 Sep 2000, Alexander Viro wrote:
Looks sane. But I really wonder if we could just do it in
create_page_buffers() if page is up-to-date. OTOH it would require attempt
to map them all. Comments?
That would certainly simplify a lot.
And as we've seen, simplifying this area
On Mon, 18 Sep 2000, Alexander Viro wrote:
We might as well do it in create_empty_buffers(), FWIW. Do you see any
case when it would mean extra work? I'm thinking about the following:
if (page is uptodate)
do get_block(...,0) for all buffers and mark them uptodate
On Mon, 18 Sep 2000, David Woodhouse wrote:
[EMAIL PROTECTED] said:
Note that with most versions of gcc this is all a complete non-issue,
as most versions of gcc will _always_ inline a function that the user
has asked to be inlined. So the issue seldom actually comes up.
I thought
On Mon, 18 Sep 2000, Torben Mathiasen wrote:
What about the case when scsi is compiled into the kernel with one or
more host adapters? We have to initialize those right away.
Actually, we don't. It's really equivalent to just having two or
more modules.
Ok, there's a test9-pre3 there now..
The SCSI stuff is pretty straightforward, and it works for me (and I also
built a kernel with all regular x86-capable SCSI drivers included, so the
others got at least that level of testing). But there are some non-x86
scsi drivers out there etc, so give it
On Tue, 19 Sep 2000, Rogier Wolff wrote:
If gcc starts shouting:
somefile.c:1234: declared inline function 'serial_paranoia_check' is
somefile.c:1234: larger than 1k. Declining to honor the inline directive.
That's not what gcc does.
Gcc silently just doesn't inline it.
And the
On Tue, 19 Sep 2000, Matthew Kirkwood wrote:
It's probably solely an init-order thing but, short of
moving the software RAID drivers into drivers/md/, I
can't see an easy way to fix it.
That would probably not be a bad fix - especially as some people want to
split up xor.c into multiple
On Tue, 19 Sep 2000, Andries Brouwer wrote:
The same here. However, reverting the 1-line change in
linux/drivers/scsi/Makefile makes things work again.
Yes, the SCSI layer is fragile wrt some initialization ordering. The devfs
setup in particular, but there might be other things there too.
In article [EMAIL PROTECTED], Dag Bakke [EMAIL PROTECTED] wrote:
Tigran Aivazian wrote:
On Mon, 18 Sep 2000, Derek Wildstar wrote:
On 18 Sep 2000, Alex Romosan wrote:
I get the same thing with a Xircon realport 10/100/modem card. Works
great in test9-pre1 and test8.
-dwild
In article [EMAIL PROTECTED],
Jeremy Higdon [EMAIL PROTECTED] wrote:
- Linux developers often do horribly stupid things, and use 64-bit
division etc instead of using a simple shift. Again, not linking
against libgcc finds those things early rather than late, because the
horribly
On Wed, 20 Sep 2000, Eric Youngdale wrote:
Some of problems that are forcing ordering requirements are better fixed
in 2.5. The cleanups to allow disk and cdrom drivers to dynamicly resize
are probably in this category. If you disagree, I can take a stab at it,
but some of the
- pre1:
- USB: OHCI controller unlink and bandwidth reclamation fixes
- USB: storage update
- sparc64: register window race. Non-deadlock rwlocks.
- name clash in hamradio/pi2.c and hamradio/pt.c
- epic100 credits, 8139too driver update, sr.c initcalls
- acenic update
On Thu, 21 Sep 2000, James Cownie wrote:
The problem
http://www.geocrawler.com/archives/3/343/2000/8/0/4140605/
which is on Alan's list to be looked at for 2.2 remains in
2.4.0.
Here is a patch for 2.4.0
I'm very nervous that this patch couldlead to horrible performance issues
due to
On Thu, 21 Sep 2000, Linus Torvalds wrote:
I would suggest an alternate patch, which would be something like
if (SIGTRAP is pending in tsk)
goto clear_dr7;
Actually, even simpler approach:
- always clear db7 after sending signal - don't test for pending
On Thu, 21 Sep 2000, M.H.VanLeeuwen wrote:
Is this patch acceptable?
Please explain.
The test seems to be that "if there are IO_APICs, a PnP irq _has_ to be an
IO_APIC irq".
+ if (!IO_APIC_IRQ(irq) io_apic_irqs)
+ return 1;
Which makes no sense to me. Why would a
On Fri, 22 Sep 2000, James Cownie wrote:
This is obviously much better (getting a signal for ALL debug register
triggers is a _good_ thing), but is it safe to call force_sig_info
from the debug trap handler if it was entered from kernel mode ?
Good question.
It should be safe. The code
On Fri, 22 Sep 2000, Andi Kleen wrote:
The problem is that the !SI_FROMUSER check in bad_signal() does not work
properly, because SI_FROMUSER does not match the defined SI_* codes (it returns
true for kernel generated signals). The result is that it always looks at
current and what
On Fri, 22 Sep 2000, Andi Kleen wrote:
No. The current process is always the same one we send the signal to, so
that test ends up being irrelevant.
Really ? I thought the original user wanted the signal to be sent to the
debugger (e.g. the idle process probably couldn't care less
On Fri, 22 Sep 2000, Andi Kleen wrote:
Unless I'm missing something switch_to does not clear debug registers on
context switch (unless another process also uses them)
You're missing something. The thing you're missing is the top of the
debug() trap handler, which handles the case of
On Fri, 22 Sep 2000, Andi Kleen wrote:
Also unless I'm missing another thing ptrace allows you to put any addresses
including kernel address into the debug registers, so you could certainly
get debug traps everywhere, making my original objection valid.
See:
if(addr
In article [EMAIL PROTECTED],
Andrea Arcangeli [EMAIL PROTECTED] wrote:
On Thu, Sep 21, 2000 at 04:11:46PM +0200, Jan Niehusmann wrote:
Yes, lvm.c and lvm-snap.c are missing from drivers/md/.
LVM and MD have nothing common.
I disagree.
Yes, they have no _code_ in common. They have a
In article [EMAIL PROTECTED],
Jeremy Higdon [EMAIL PROTECTED] wrote:
In my case, it is simple "long long" arithmetic. Shifts, ANDs, ORs,
comparisons, etc. Not even any addition (which should be pretty efficient
with the HW carry bit on X86). I don't know why:
Oh, I agree. In your case this
This should fix the VM deadlocks (knock wood), and adds the infrastructure
for better samba serving. And lots of small details...
Linus
-
- pre1:
- USB: OHCI controller unlink and bandwidth reclamation fixes
- USB: storage update
- sparc64: register window
In article [EMAIL PROTECTED],
Jon Evans [EMAIL PROTECTED] wrote:
On Fri, Sep 22, 2000 at 09:14:23AM -0400, Kernel Related Emails wrote:
Well everythings working fine in test9-pre5 except for the fact that sound
has stopped functioning on my es1371 card. I had no problems with it at
all in
In article 8qk483$4ua$[EMAIL PROTECTED],
Linus Torvalds [EMAIL PROTECTED] wrote:
Go into "drivers/sound/ac97_codec.c" to around line 570 or so, and
comment out the line that says
current-state = TASK_UNINTERRUPTIBLE;
and see if that fixes the problem.
Nope. But I found anoth
On Sun, 24 Sep 2000, Jeff Garzik wrote:
h The patch was submitted by me, but it came straight from
2.2.x... after being whipped, I shall look into both versions of
ac97_codec some more...
The "-id" field has nothing to do with the device ID number, it's a
"which codec is this"
On Sun, 24 Sep 2000, Ingo Molnar wrote:
as a longer term solution, i'm wondering how hard it would be to propagate
gfp_mask into the shrink_*() functions, and prevent recursion similarly to
the swap-out logic? This way even GFP_BUFFER allocators could touch/free
the dcache/icache.
Well,
On Sun, 24 Sep 2000, Ingo Molnar wrote:
i just found this out by example, i'm running the shrink_[i|d]cache stuff
even if __GFP_IO is not set, and no problems so far. (and much better
balancing behavior)
Send me the tested patch (and I'd suggest moving the shm_swap() test into
shm_swap()
[ Sorry to follow up on myself.. ]
On Sun, 24 Sep 2000, Linus Torvalds wrote:
Send me the tested patch (and I'd suggest moving the shm_swap() test into
shm_swap() too, so that refill_inactive() gets cleaned up a bit).
I think that shm_swap still needs it - it's doing things
On Sun, 24 Sep 2000, Andrea Arcangeli wrote:
On Sun, Sep 24, 2000 at 10:26:11PM +0200, Ingo Molnar wrote:
where will it deadlock?
ext2_new_block (or whatever that runs getblk with the superlock lock
acquired)-getblk-GFP-shrink_dcache_memory-prune_dcache-
Hmm..
Thinking some more about this issue, I actually suspect that there's a
better solution.
The fact is that GFP_BUFFER is only used for the old-fashioned buffer
block allocations, and anything that uses the page cache automatically
avoids the whole issue. As such, from a VM balancing
On Mon, 25 Sep 2000, Alexander Viro wrote:
On Sun, 24 Sep 2000, Linus Torvalds wrote:
The remaining part if the directory handling. THAT is very buffer-cache
intensive, as the directory handling hasn't been moved over to the page
cache at all for ext2. Doing a large "find"
On Mon, 25 Sep 2000, Rik van Riel wrote:
Hmmm, doesn't GFP_BUFFER simply imply that we cannot
allocate new buffer heads to do IO with??
No.
New buffer heads would be ok - recursion is fine in theory, as long as it
is bounded, and we might bound it some other way (I don't think we
_should_
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
But I'd much prefer to pass not only the classzone from allocator
to memory balancing, but _also_ the order of the allocation,
and then shrink_mmap will know it doesn't worth to free anything
that isn't contigous on the order of the allocation
Duh. This was a really stupid bug.
In kernel/signal.c, collect_signal(), for the case where we don't find a
siginfo block, we need to clear the signal set.
In short, add the line
sigdelset(list-signal, sig);
just before the first "return 1" in collect_signal(), and all should be
well
On Tue, 26 Sep 2000, Andrea Arcangeli wrote:
I'm talking about the fact that if you have a file mmapped in 1.5G of RAM
test9 will waste time rolling between LRUs 384000 pages, while classzone
won't ever see 1 of those pages until you run low on fs cache.
What drugs are you on? Nobody
On Tue, 26 Sep 2000, Andrea Arcangeli wrote:
The machine will run low on memory as soon as I read 200mbyte from disk.
So?
Yes, at that point we'll do the LRU dance. Then we won't be low on memory
any more, and we won't do the LRU dance any more. What's the magic in
zoneinfo that makes it
VM balacing fixes, sound should work again, and a lot of small details.
Linus
-
- pre1:
- USB: OHCI controller unlink and bandwidth reclamation fixes
- USB: storage update
- sparc64: register window race. Non-deadlock rwlocks.
- name clash in hamradio/pi2.c
On Tue, 26 Sep 2000, Arjan van de Ven wrote:
And the network-stack in net/core/sock.c:sock_alloc_send_skb which sounds
like a bug in this case, and might even be the cause of too many GFP_BUFFER
allocations in loads suchs as Ingo's.
Hey, good grepping.
That looks like just complete
On Tue, 26 Sep 2000, Jeff Garzik wrote:
On Mon, 25 Sep 2000, Linus Torvalds wrote:
- pre7:
- official Compaq CISS driver.
He may be the maintainer, but he needs a good spanking...
No, the breakage is probably mine.
The problem was that you sent me the forward-port of Alan's
On Fri, 29 Sep 2000, Alan Cox wrote:
In solo1_probe, an FM interface is registered.
So, IMHO there is a bug somewhere... Why register an FM interface in
probe, and then check_region for another FM driver in _open? Is this
intentional or really a bug?
The I/O port range is only
Last pre-kernel - I'll do the real test9 before I fly off to Germany on
Tuesday.
Linus
---
- pre8:
- initialize to zero - put it in the .bss instead
- no extended dumb serial driver options, if no dumb serial driver
- access() on a special file on a read-only
Why do you apparently ignore the fact that page-out write-back performance
is horribly crappy because it always starts out doing synchronous writes?
I pointed out previously in a private email that page_launder() must be
buggy as it stands now, you seem to have ignored that part (and the
Noticeable: the IDE initialization, more VM work, and MD should work in
every configuration.
Famous last words.
Linus
-
- pre9:
- USB: documentation.
- Yeah. MD/LVM should really be fixed this time.
- SH architecture update
- i810 RNG driver update
-
On Mon, 18 Sep 2000, Alexander Viro wrote:
but should instead be
static int make_buffer_uptodate(struct page *page, struct buffer_head * bh)
{
if (Page_Uptodate(page)) {
^^^
set_bit(BH_Uptodate,
On Mon, 18 Sep 2000, Alexander Viro wrote:
* we have several bh state components and the thing is a big,
fscking mess. If we look at the areas outside of the page lock we have:
It's not a mess at all.
I don't see why you call things "first stage" etc. It's perfectly
straightforward.
On Tue, 3 Oct 2000, Matti Aarnio wrote:
Just FYI. THAT can't be MIME (quoted printable) error.
Oh, but it is.
The '=' is very special in MIME QP, and as the '+=' at
that very same line has not been turned into '+=3D', it
wasn't QP encoding happenstance.
That's simply
- final:
- USB: ohci controller update, round-robin device numbering
- ksymoops moved: document
- sparc updates
- sg.c: get rid of more #ifdef MODULE code
- pre9:
- USB: documentation.
- Yeah. MD/LVM should really be fixed this time.
- SH architecture update
-
On Tue, 19 Sep 2000, Andrea Arcangeli wrote:
I think we can remove all the __dummy stuff and put the "memory" in such asm
statements.
Comments?
Have you looked at the code it generates? Quite sad, really.
Linus
-
To unsubscribe from this list: send the line
On Mon, 18 Sep 2000, David S. Miller wrote:
Did you try to boot these kernels containing scsi devices you
don't have? I don't see how it could work (actually I do, see
below).
Hmm..
Why would this not have happened for a module?
I agree that the thing looks fishy. But this is not new
On Thu, 7 Sep 2000, Jamie Lokier wrote:
asm *__volatile__* seems to make no difference. I've tried a few things.
Andrea Arcangeli wrote:
Maybe we can rely on the __volatile__ statement of the asm that will
enforce that if we write:
*p = 0;
__asm__ __volatile__("" : :);
On Thu, 7 Sep 2000, Jamie Lokier wrote:
It's ok for the compiler to do that (given we don't know what "volatile"
means anyway :-). But it does have implications for spin_lock:
spin_lock must say that it clobbers memory.
Yup. We should just fix that.
Linus
-
To
On Thu, 7 Sep 2000, Andrea Arcangeli wrote:
On Mon, 4 Sep 2000, Andrea Arcangeli wrote:
barrier()). I also noticed __sti()/__save_flags() doesn't need to clobber
"memory".
I'm not sure anymore if __sti and spin_unlock() doesn't need to clobber
memory (it looks necessary to make sure
On Mon, 18 Sep 2000, Olivier Galibert wrote:
On Mon, Sep 18, 2000 at 05:51:43PM -0700, Linus Torvalds wrote:
Why would this not have happened for a module?
I agree that the thing looks fishy. But this is not new code, and it has
worked previously. What changed?
Maybe nobody ever
On Tue, 19 Sep 2000, David S. Miller wrote:
Would you mind taking a look at the difference in code output when
register pressure in a given function is moderate to high? :-)
Immaterial.
If somebody cares about performance, they'd just better create the proper
architecture-specific
On Fri, 22 Sep 2000, Andrea Arcangeli wrote:
This patch fixes the spinlock problems in read_lock/write_lock and also some
alpha SMP race where clear_bit isn't enforcing a memory barrier
Why would clear_bit() be a memory barrier?
Anything that expects clear_bit() to be a memory barrier
On Fri, 22 Sep 2000, Molnar Ingo wrote:
i'm still getting VM related lockups during heavy write load, in
test9-pre5 + your 2.4.0-t9p2-vmpatch (which i understand as being your
last VM related fix-patch, correct?). Here is a histogram of such a
lockup:
Rik,
those VM patches are going
On Fri, 22 Sep 2000, Andrea Arcangeli wrote:
If you don't like the name smp_mb__before/after_clear_bit (not that I like it
too much too) suggestions are welcome. Maybe we could use a single
smp_mb__across_bitops() instead?
I suspect that we should just split up the bitops.
We've done this
On Tue, 3 Oct 2000, Matti Aarnio wrote:
Linus, please use MUTT or PINE -- hmm... you do use PINE, so what
is the problem at receiving MIME attachments, or QP encoded material
at all ? (Aside of pine possibly saving/piping non-decoded QP
text/plain message into
On Wed, 4 Oct 2000, Rik van Riel wrote:
The potential for this bug has been around since 2.3.51, when
different balance_ratios for different zones became possible.
No, the bug has been around since your VM.
You must NOT depend on some global "freepages" thing.
You MUST do your freepages
On Thu, 5 Oct 2000, Torben Mathiasen wrote:
This patch is a resend of my other link fix patch that didn't get
in test9-pre9. I assume this is because of some other changes
to upper layer scsi drivers.
No, I just felt it was too big, and with not enough reason for it at all.
At this
On Sun, 8 Oct 2000, Russell King wrote:
The only time that minix_new_inode sets *error is if it succeeds! The
same applies to minix_mknod, minix_mkdir, and minix_symlink. With this
fixed, the above oops no longer happens. Here is a patch to fix this.
This makes minix follow the same
201 - 300 of 24431 matches
Mail list logo
