On Mon, 19 Mar 2007, Linus Torvalds wrote:
So *please* don't believe that you can make it as cheap to have some
automatic fixup of two sequences, one inlined and one as a call. It may
look so when you look at the single instruction generated, but you're
ignoring all the instructions
Eric W. Biederman wrote:
Rusty Russell [EMAIL PROTECTED] writes:
On Sun, 2007-03-18 at 13:08 +0100, Andi Kleen wrote:
The idea is _NOT_ that you go look for references to the paravirt_ops
members structure, that would be stupid and you wouldn't be able to
use the most efficient
From: David Howells [EMAIL PROTECTED]
Date: Mon, 19 Mar 2007 15:41:38 +
Alan Cox [EMAIL PROTECTED] wrote:
So use SOCK_DGRAM, its clearly near enough.
No, it's not. SOCK_DGRAM is an unreliable, unidirectional datagram passing
service.
David we're not looking for a precise match, so
Linus Torvalds wrote:
On Mon, 19 Mar 2007, Eric W. Biederman wrote:
True. You can use all of the call clobbered registers.
Quite often, the biggest single win of inlining is not so much the code
size (although if done right, that will be smaller too), but the fact that
inlining
From: Jeremy Fitzhardinge [EMAIL PROTECTED]
Date: Mon, 19 Mar 2007 12:10:08 -0700
All this is doable; I'd probably end up hacking boot/compressed/relocs.c
to generate the appropriate reloc table. My main concern is hacking the
kernel build process itself; I'm unsure of what it would actually
David Miller wrote:
Another point worth making is that for function calls you
can fix things up lazily if you want.
[...]
In fact forget I mentioned this idea :)
OK :) I think we'll only ever want to bind to a hypervisor once, since
the underlying hypervisor can't change on the fly
-stable review patch. If anyone has any objections, please let us know.
--
From: Samuel Ortiz [EMAIL PROTECTED]
Without this initialization one gets
kernel BUG at kernel/rtmutex_common.h:80!
This patch should also be included in the -stable kernel.
Signed-off-by: G.
I got it the first time, it's just very low priority and very
deep in my backlog and I'm also about to be away for 3 days.
I have it so you don't need to keep resending it.
Thanks.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
Possibly not, but I'd like to be able to say with confidence that
running a PARAVIRT kernel on bare hardware has no performance loss
compared to running a !PARAVIRT kernel. There's the case of small
instruction sequences which have been replaced with calls (such as
sti/cli/push;popf/etc),
On Mon, 2007-03-19 at 11:38 -0700, Linus Torvalds wrote:
On Mon, 19 Mar 2007, Eric W. Biederman wrote:
True. You can use all of the call clobbered registers.
Quite often, the biggest single win of inlining is not so much the code
size (although if done right, that will be smaller
From: Adrian Bunk [EMAIL PROTECTED]
Date: Mon, 19 Mar 2007 10:24:03 +0100
This patch fixes two NULL dereferences spotted by the Coverity checker.
For a better understanding, the diff -uwp output (that ignores the
indentation changes) is:
I'll apply this, thanks Adrian.
-
To unsubscribe
Jeremy Fitzhardinge wrote:
For example, say we wanted to put a general call for sti into entry.S,
where its expected it won't touch any registers. In that case, we'd
have a sequence like:
push %eax
push %ecx
push %edx
call paravirt_cli
pop %edx
pop %ecx
pop %eax
Zachary Amsden wrote:
Jeremy Fitzhardinge wrote:
If we then work out in each direction and see matched push/pops,
then we know what registers can be trashed in the call. This also
allows us to determine the callsite size, and therefore how much space
we need for inlining.
No, that is
Rusty Russell wrote:
On Mon, 2007-03-19 at 11:38 -0700, Linus Torvalds wrote:
On Mon, 19 Mar 2007, Eric W. Biederman wrote:
True. You can use all of the call clobbered registers.
Quite often, the biggest single win of inlining is not so much the code
size (although if done
From: Adrian Bunk [EMAIL PROTECTED]
Date: Sun, 18 Mar 2007 19:49:38 +0100
Subject: ipv6 crash
References : http://lkml.org/lkml/2007/3/10/2
Submitter : Len Brown [EMAIL PROTECTED]
Status : unknown
This is caused by some problem in the router round-robin code in
Tony Vroon wrote:
The first user of ata_ac_issue_prot_with_ledtrigger, the ServerWorks Frodo/
Apple K2 driver. Used by the IDE LED trigger on G5 towers.
Respin of an earlier patch, based on comments by Tejun Heo Alan Cox.
Just two comments.
1. IMHO, ata_qc_issue_prot_ledtrigger() without
Here are some USB fixes and new device ids against 2.6.21-rc4.
These patches contain a fix for a regression that is on Adrian's list
with regards to usb-serial drivers oopsing, and they also add a number
of different device ids and other minor updates.
All of these have been in the -mm releases.
On Mon, Mar 19, 2007 at 03:01:25PM -0700, Chris Wright wrote:
* Greg KH ([EMAIL PROTECTED]) wrote:
From: Chris Wright [EMAIL PROTECTED]
[IPV6] fix ipv6_getsockopt_sticky copy_to_user leak
User supplied len 0 can cause leak of kernel memory.
Use unsigned compare instead.
You can
On Mon, Mar 19, 2007 at 05:48:55PM -0400, Dmitry Torokhov wrote:
On 3/19/07, Greg KH [EMAIL PROTECTED] wrote:
-stable review patch. If anyone has any objections, please let us know.
--
From: Dmitry Torokhov [EMAIL PROTECTED]
Input: i8042 - fix AUX IRQ delivery check
Randy Dunlap wrote:
The we duplicate all the relevant /proc knobs:
cat /proc/sys/vm/dirty_ratio
30
cat /proc/sys/vm/hires-dirty_ratio/
30
Or we do something else ;)
Sounds better. I wasn't very keen on the userspace interface that this
exposed. Will look at those.
Okay... may be I
On Sat, Mar 17, 2007 at 02:26:57PM +0100, Andi Kleen wrote:
Arjan van de Ven [EMAIL PROTECTED] writes:
well we can do the handshake to take ownership like we do much later in
boot, but that requires PCI to be there and fully discovered, which we
don't have this early.
That's not true
Christoph Lameter writes:
+static inline void *quicklist_alloc(int nr, gfp_t flags, void (*ctor)(void
*))
+{
...
+ p = (void *)__get_free_page(flags | __GFP_ZERO);
This will cause problems on 64-bit powerpc, at least with 4k pages,
since the pmd and pgd levels only use 1/4 of a page.
Temporarily at
http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/
- Restored the RSDL CPU scheduler (a new version thereof)
Boilerplate:
- See the `hot-fixes' directory for
On Tue, 20 Mar 2007 13:47:53 +1100 Nick Piggin [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
On Mon, 19 Mar 2007 17:58:52 -0800 Andrew Morton [EMAIL PROTECTED] wrote:
The kernel without Nick's patchset but with the assert runs OK too. Under
the principle of
On 3/16/07, Thomas Gleixner [EMAIL PROTECTED] wrote:
Yes, this is probably caused by SMM code trying to emulate a PS/2
keyboard from a (maybe connected or not) USB keyboard. Unfortunately we
have no way to disable this BIOS misfeature in the early boot process.
On Monday 19 March 2007, Greg KH wrote:
This is the start of the stable review cycle for the 2.6.20.4 release.
There are 31 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let us know. If anyone is a maintainer of
Andrew Morton wrote:
On Tue, 20 Mar 2007 13:47:53 +1100 Nick Piggin [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
Hang on a sec... I'll try fixing the thing before you next make a
release.
Too late. hot-fixes/ awaits thee.
Awww... well thanks very much Michal for reporting the bug,
Nick Piggin wrote:
Andrew Morton wrote:
On Tue, 20 Mar 2007 13:47:53 +1100 Nick Piggin
[EMAIL PROTECTED] wrote:
Andrew Morton wrote:
Hang on a sec... I'll try fixing the thing before you next make a
release.
Too late. hot-fixes/ awaits thee.
Awww... well thanks very much Michal
On Tue, 2007-20-03 at 01:04 -0400, Lee Revell wrote:
I think CONFIG_TRY_TO_DISABLE_SMI would be excellent for debugging,
not to mention people trying to spec out hardware for RT
applications...
There is a SMI disabling module in RTAI, check the smi-module.c in this:
On Mon, Mar 19, 2007 at 09:44:28PM +0100, Blaisorblade wrote:
On Sunday 18 March 2007 03:50, Nick Piggin wrote:
Yes, I believe that is the case, however I wonder if that is going to
be a problem for you to distinguish between write faults for clean
writable ptes, and write faults
Rik van Riel wrote:
Split the anonymous and file backed pages out onto their own pageout
queues. This we do not unnecessarily churn through lots of anonymous
pages when we do not want to swap them out anyway.
This should (with additional tuning) be a great step forward in
scalability, allowing
On Mon, Mar 19, 2007 at 08:11:55PM -0700, Linus Torvalds wrote:
Quite frankly, I was *planning* on merging RSDL very early after 2.6.21,
but there is one thing that has turned me completely off the whole thing:
- the people involved seem to be totally unwilling to even admit there
On Mon, 2007-03-19 at 20:05 -0500, Matt Mackall wrote:
On Tue, Mar 20, 2007 at 01:42:46AM +0100, Thomas Gleixner wrote:
On Mon, 2007-03-19 at 17:32 -0500, Matt Mackall wrote:
This is exactly the same problem as booting on a desktop PC. But
somehow LILO manages. My first Linux box had a
On Mon, 2007-03-19 at 21:27 -0700, Greg KH wrote:
On Sat, Mar 17, 2007 at 02:26:57PM +0100, Andi Kleen wrote:
Arjan van de Ven [EMAIL PROTECTED] writes:
well we can do the handshake to take ownership like we do much later in
boot, but that requires PCI to be there and fully
OGAWA Hirofumi wrote:
Alexander E. Patrakov [EMAIL PROTECTED] writes:
But, anyway, this is a separate issue that my patch doesn't attempt to
correct. The conclusion so far is that we disagree, and that there are
situations where using utf8 iocharset is the least of all evils, so the
warning
On Thu, 15 Mar 2007 15:10:23 +0100 Michal Januszewski [EMAIL PROTECTED] wrote:
On a multiprocessor machine the VT_WAITACTIVE ioctl call may return 0
if fg_console has already been updated in redraw_screen(), but the
console switch itself hasn't been completed. Fix this by checking
fg_console
On Mon, Mar 19, 2007 at 11:32:27AM +0100, Marco Berizzi wrote:
Marco Berizzi wrote:
David Chinner wrote:
Ok, so an ipsec change. And I see from the history below it
really has nothing to do with this problem. it seems the problem
has something to do with changes between 2.6.19.1 and
Dell SC1425 x86_64 running in i386 mode (the problem also occurs in
x86_64 mode). Kernel 2.6.21-rc4, gcc 4.1.0. Config extract at end.
Booting with 'console=tty console=ttyS0,9600'. The serial console on
ttyS0 (0x3f8, irq 4) is probed twice, once from serial8250_init() and
again from
I've attached a patch below the optimizes this code path for powerpc,
but the scheme applies to all architectures aswell. It just rips out all
the callachin madness, and does as good as it gets in the pagefault
handler:
NAK, patch on the way to get rid of all the debugger() crap by using
Christoph Hellwig wrote:
On Mon, Mar 19, 2007 at 09:11:31PM +1100, Nick Piggin wrote:
I've got the patches in -mm now. I hope they will get merged when the
the next window opens.
I didn't submit the -page_mkwrite conversion yet, because I didn't
have any callers to look at. It is is slightly
On Mon, 2007-03-19 at 18:00 -0800, Zachary Amsden wrote:
Rusty Russell wrote:
*This* was the reason that the current hand-coded calls only clobber %
eax. It was a compromise between native (no clobbers) and others (might
need a reg).
I still don't think this was a good trade.
...
Xen
Zachary Amsden wrote:
For VMI, the default clobber was cc, and you need a way to allow at
least that, because saving and restoring flags is too expensive on x86.
According to lore (Andi, I think), asm() always clobbers cc.
I still don't think this was a good trade. The primary motivation
On Monday 19 March 2007 00:46, Jeremy Fitzhardinge wrote:
Andi Kleen wrote:
Yes. All inline assembly tells gcc what registers are clobbered
and it fills in the tables. Hand clobbering in inline assembly cannot
be expressed with the current toolchain, so we moved all those
out of line.
Andi Kleen wrote:
push %eax
push %ecx
push %edx
call paravirt_cli
pop %edx
pop %ecx
pop %eax
This cannot right now be expressed as inline assembly in the unwinder at all
because there is no way to inject the push/pops into the compiler generated
From: Andi Kleen [EMAIL PROTECTED]
Date: Mon, 19 Mar 2007 11:57:28 +0100
On Monday 19 March 2007 00:46, Jeremy Fitzhardinge wrote:
Andi Kleen wrote:
For example, say we wanted to put a general call for sti into entry.S,
where its expected it won't touch any registers. In that case, we'd
It's inability to handle sequences like the above sounds to me like
a very good argument to _not_ merge the unwinder back into the tree.
The unwinder can handle it fine, it is just that gcc right now cannot
be taught to generate correct unwind tables for it. If paravirt ops
is widely used i
From: Linus Torvalds [EMAIL PROTECTED]
Date: Mon, 19 Mar 2007 20:18:14 -0700 (PDT)
Please don't subject us to another couple months of hair-pulling only
to have Linus yank the thing out again, there are certainly more
useful things to spend time on :-)
Good call. Dwarf2 unwinding
David Miller [EMAIL PROTECTED] writes:
From: Linus Torvalds [EMAIL PROTECTED]
Date: Mon, 19 Mar 2007 20:18:14 -0700 (PDT)
Please don't subject us to another couple months of hair-pulling only
to have Linus yank the thing out again, there are certainly more
useful things to spend time
In todays 2.6.21-rc4+git the following news warning has appeared on my
ppc computer:
CC [M] drivers/ata/libata-core.o
drivers/ata/libata-core.c: In function 'ata_sg_clean':
drivers/ata/libata-core.c:3558: warning: unused variable 'dir'
--
Meelis Roos ([EMAIL PROTECTED])
-
To unsubscribe
Let's not bore people running -rc kernels with regressions that have
patches available - let's get this patches into the tree for giving
them the pure exciting experience of the many unfixed regressions.
This email lists some known regressions in Linus' tree compared to 2.6.20
with patches
Jim Gettys wrote:
On Sun, 2007-03-18 at 17:07 +0100, Ingo Molnar wrote:
* Pavel Machek [EMAIL PROTECTED] wrote:
Some day we may have modesetting support in the kernel for some
graphics hw, right now it's pretty damn spotty.
Yep, that's the way to go.
hey, i wildly supported this approach
On Mon, 2007-03-19 at 16:33 -0400, Bill Davidsen wrote:
What you say sounds good, assuming that the cost of a sleep is less than
the cost of the busy wait. But this may be hardware, the waits may be
very small and frequent, and if it's hitting a small hardware window
like retrace, delays
Hello!
Well I don't think the loopback device is currently but as soon
as we get network namespace support we will have multiple loopback
devices and they will get unregistered when we remove the network
namespace.
There is no logical difference. At the moment when namespace is gone
there is
Hello!
Does this look sane (untested)?
It does not, unfortunately.
Instead of regular crash in infiniband you will get numerous
random NULL pointer dereferences both due to dst-neighbour
and due to dst-dev.
Alexey
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
Quoting Alexey Kuznetsov [EMAIL PROTECTED]:
Subject: Re: [ofa-general] Re: dst_ifdown breaks infiniband?
Does this look sane (untested)?
It does not, unfortunately.
Instead of regular crash in infiniband you will get numerous
random NULL pointer dereferences both due to dst-neighbour
Hello!
I think the thing to do is to just leave the loopback references
in place, try to unregister the per-namespace loopback device,
and that will safely wait for all the references to go away.
Yes, it is exactly how it works in openvz. All the sockets are killed,
queues are cleared, nobody
Any simpler ideas?
Well, if inifiniband destructor really needs to take that lock... no.
Right now I do not see.
OK, this is actually not hard to fix - for infiniband, we can just look at
neighbour-dev-type or compare neighbour-dev and
neighbour-parms-dev - if they are different, device is
Quoting Michael S. Tsirkin [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Any simpler ideas?
Well, if inifiniband destructor really needs to take that lock... no.
Right now I do not see.
OK, this is actually not hard to fix - for infiniband, we can just look at
Hello!
If a device driver sets neigh_destructor in neigh_params, this could
get called after the device has been unregistered and the driver module
removed.
It is the same problem: if dst-neighbour holds neighbour, it should
not hold device. parms-dev is not supposed to be used after
Quoting Alexey Kuznetsov [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Hello!
If a device driver sets neigh_destructor in neigh_params, this could
get called after the device has been unregistered and the driver module
removed.
It is the same problem: if
Quoting Alexey Kuznetsov [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Hello!
If a device driver sets neigh_destructor in neigh_params, this could
get called after the device has been unregistered and the driver module
removed.
It is the same problem: if
Hello!
infiniband sets parm-neigh_destructor, and I search for a way to prevent
this destructor from being called after the module has been unloaded.
Ideas?
It must be called in any case to update/release internal ipoib structures.
The idea is to move call of parm-neigh_destructor from
David Miller [EMAIL PROTECTED] writes:
I think the thing to do is to just leave the loopback references
in place, try to unregister the per-namespace loopback device,
and that will safely wait for all the references to go away.
Right. The only thing I have found that needs to be changed so
Quoting Alexey Kuznetsov [EMAIL PROTECTED]:
Subject: Re: dst_ifdown breaks infiniband?
Hello!
infiniband sets parm-neigh_destructor, and I search for a way to prevent
this destructor from being called after the module has been unloaded.
Ideas?
It must be called in any case to
Hello!
This might work. Could you post a patch to better show what you mean to do?
Here it is.
-neigh_destructor() is killed (not used), replaced with -neigh_cleanup(),
which is called when neighbor entry goes to dead state. At this point
everything is still valid: neigh-dev, neigh-parms etc.
901 - 965 of 965 matches
Mail list logo
