.
>
> Juergen Gross <jgr...@suse.com> writes:
>
>> Mails to chr...@sous-sol.org are not deliverable since several months.
>> Drop him as PARAVIRT_OPS maintainer.
>>
>> Signed-off-by: Juergen Gross <jgr...@suse.com>
Acked-by: Chris Wright <chr...@redhat.c
rites:
>
>> Mails to chr...@sous-sol.org are not deliverable since several months.
>> Drop him as PARAVIRT_OPS maintainer.
>>
>> Signed-off-by: Juergen Gross
Acked-by: Chris Wright
;)
thanks,
-chris
>> ---
>> MAINTAINERS | 1 -
>> 1 file changed
* Guenter Roeck (li...@roeck-us.net) wrote:
> On Thu, Jul 11, 2013 at 12:00:54PM -0700, Chris Wright wrote:
> > * Guenter Roeck (li...@roeck-us.net) wrote:
> > > On Tue, Jul 09, 2013 at 04:22:52PM -0700, Chris Wright wrote:
> > > > One thing I've seen is the BIOS zer
* Guenter Roeck (li...@roeck-us.net) wrote:
> On Tue, Jul 09, 2013 at 04:22:52PM -0700, Chris Wright wrote:
> > One thing I've seen is the BIOS zeroing the base register address when
> > VT-d is disabled in BIOS. So, Guenter, a "fix" may be simply enabling
> > VT-d
* Guenter Roeck (li...@roeck-us.net) wrote:
On Tue, Jul 09, 2013 at 04:22:52PM -0700, Chris Wright wrote:
One thing I've seen is the BIOS zeroing the base register address when
VT-d is disabled in BIOS. So, Guenter, a fix may be simply enabling
VT-d in the BIOS.
Ah, yes, I think I may
* Guenter Roeck (li...@roeck-us.net) wrote:
On Thu, Jul 11, 2013 at 12:00:54PM -0700, Chris Wright wrote:
* Guenter Roeck (li...@roeck-us.net) wrote:
On Tue, Jul 09, 2013 at 04:22:52PM -0700, Chris Wright wrote:
One thing I've seen is the BIOS zeroing the base register address when
* Guenter Roeck (li...@roeck-us.net) wrote:
> On Tue, Jul 09, 2013 at 04:22:52PM -0700, Chris Wright wrote:
> > * Guenter Roeck (li...@roeck-us.net) wrote:
> > > On Tue, Jul 09, 2013 at 03:05:39PM -0600, Bjorn Helgaas wrote:
> > > > [+cc Joerg, David, iommu list]
* Guenter Roeck (li...@roeck-us.net) wrote:
> On Tue, Jul 09, 2013 at 03:05:39PM -0600, Bjorn Helgaas wrote:
> > [+cc Joerg, David, iommu list]
> >
> > On Tue, Jul 9, 2013 at 2:24 PM, Guenter Roeck wrote:
> > > I started seeing this problem after updating the BIOS trying fix another
> > >
* Guenter Roeck (li...@roeck-us.net) wrote:
On Tue, Jul 09, 2013 at 03:05:39PM -0600, Bjorn Helgaas wrote:
[+cc Joerg, David, iommu list]
On Tue, Jul 9, 2013 at 2:24 PM, Guenter Roeck li...@roeck-us.net wrote:
I started seeing this problem after updating the BIOS trying fix another
* Guenter Roeck (li...@roeck-us.net) wrote:
On Tue, Jul 09, 2013 at 04:22:52PM -0700, Chris Wright wrote:
* Guenter Roeck (li...@roeck-us.net) wrote:
On Tue, Jul 09, 2013 at 03:05:39PM -0600, Bjorn Helgaas wrote:
[+cc Joerg, David, iommu list]
On Tue, Jul 9, 2013 at 2:24 PM
It's only used locally, no need to pollute global namespace.
Signed-off-by: Chris Wright
---
fs/debugfs/inode.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index 4733eab..2c9fafb 100644
--- a/fs/debugfs/inode.c
+++ b/fs
It's only used locally, no need to pollute global namespace.
Signed-off-by: Chris Wright chr...@sous-sol.org
---
fs/debugfs/inode.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index 4733eab..2c9fafb 100644
--- a/fs/debugfs
* Oliver Pinter ([EMAIL PROTECTED]) wrote:
> mainline: ecaf18c15aac8bb9bed7b7aa0e382fe252e275d5
>
> --->8---
> commit ecaf18c15aac8bb9bed7b7aa0e382fe252e275d5
> Author: Eric Paris <[EMAIL PROTECTED]>
> Date: Tue Dec 4 23:45:31 2007 -0800
>
> VM/Security: add security hook to do_brk
>
>
* Oliver Pinter ([EMAIL PROTECTED]) wrote:
mainline: ecaf18c15aac8bb9bed7b7aa0e382fe252e275d5
---8---
commit ecaf18c15aac8bb9bed7b7aa0e382fe252e275d5
Author: Eric Paris [EMAIL PROTECTED]
Date: Tue Dec 4 23:45:31 2007 -0800
VM/Security: add security hook to do_brk
Given a
* Glauber de Oliveira Costa ([EMAIL PROTECTED]) wrote:
> lookup_address() receives two parameters, but efi_64.c call
> is passing only one. It's actually preventing the tree from compiling
>
> Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
Good catch, I know I don't test with
* Glauber de Oliveira Costa ([EMAIL PROTECTED]) wrote:
lookup_address() receives two parameters, but efi_64.c call
is passing only one. It's actually preventing the tree from compiling
Signed-off-by: Glauber de Oliveira Costa [EMAIL PROTECTED]
Good catch, I know I don't test with
Refactor ioport unification to pull out common code.
Cc: [EMAIL PROTECTED]
Cc: Kevin Winchester <[EMAIL PROTECTED]>
Cc: Zach Brown <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: "H. Peter Anvin" <[EMAIL PROTECTED]>
Cc: Thomas Gleixner <[EMAIL PR
Miguel's (can respin to standalone if that's better).
Tested (on both 32 and 64-bit) with simple:
#include
#include
main()
{
if (iopl(3) == 0)
asm ("cli\nsti\n"::);
}
thanks,
-chris
--
From: Chris Wright <[EMAIL PROTECTED]>
Subject: [PATCH] x8
Refactor ioport unification to pull out common code.
Cc: [EMAIL PROTECTED]
Cc: Kevin Winchester [EMAIL PROTECTED]
Cc: Zach Brown [EMAIL PROTECTED]
Cc: Ingo Molnar [EMAIL PROTECTED]
Cc: H. Peter Anvin [EMAIL PROTECTED]
Cc: Thomas Gleixner [EMAIL PROTECTED]
Signed-off-by: Chris Wright [EMAIL
respin to standalone if that's better).
Tested (on both 32 and 64-bit) with simple:
#include stdlib.h
#include sys/io.h
main()
{
if (iopl(3) == 0)
asm (cli\nsti\n::);
}
thanks,
-chris
--
From: Chris Wright [EMAIL PROTECTED]
Subject: [PATCH] x86: fix ioport
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
> On Thu, 3 Jan 2008, Chris Wright wrote:
> > Yes, paravirt ops have a well-specified calling convention (register
> > based). There was a cleanup that Andi did that caused the problem
> > because it removed all the "f
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
> Hmm, I know paravirt-ops had an issue with mcount in the RT tree. I can't
> remember the exact issues, but it did have something to do with the way
> parameters were passed in.
>
> Chris, do you remember what the issues were?
Yes, paravirt ops have a
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
Hmm, I know paravirt-ops had an issue with mcount in the RT tree. I can't
remember the exact issues, but it did have something to do with the way
parameters were passed in.
Chris, do you remember what the issues were?
Yes, paravirt ops have a
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
On Thu, 3 Jan 2008, Chris Wright wrote:
Yes, paravirt ops have a well-specified calling convention (register
based). There was a cleanup that Andi did that caused the problem
because it removed all the fastcall annotations since -mregparm=3
> forked from a parent created when audit was enabled to not take the fastest
> syscall path thru entry.S
>
> Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Yeah, I think that's the right thing to do. Doesn't have an
audit_context anyway.
Acked-by: Chris Wright <[EMAI
when audit was enabled to not take the fastest
syscall path thru entry.S
Signed-off-by: Tony Jones [EMAIL PROTECTED]
Yeah, I think that's the right thing to do. Doesn't have an
audit_context anyway.
Acked-by: Chris Wright [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
> Do other people want to stand up and be "LSM maintainers" in the sense
> that they also end up being informed members who can also stand up for new
> modules and help merge them, rather than just push the existing one(s)?
> Chris? Casey? Crispin?
* Casey Schaufler ([EMAIL PROTECTED]) wrote:
> And don't give me the old "LKML is a tough crowd" feldercarb.
> Security modules have been much worse. Innovation, even in
> security, is a good thing and treating people harshly, even
> "for their own good", is an impediment to innovation.
I agree
* Casey Schaufler ([EMAIL PROTECTED]) wrote:
And don't give me the old LKML is a tough crowd feldercarb.
Security modules have been much worse. Innovation, even in
security, is a good thing and treating people harshly, even
for their own good, is an impediment to innovation.
I agree that
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
Do other people want to stand up and be LSM maintainers in the sense
that they also end up being informed members who can also stand up for new
modules and help merge them, rather than just push the existing one(s)?
Chris? Casey? Crispin?
Stephen
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> Chris Wright wrote:
> > Yes, and I think we can still improve performance although I can't see
> > anyway to help out the modular case, so I guess it will have to incur
> > the hit that's always been there.
>
> Br
* Jan Engelhardt ([EMAIL PROTECTED]) wrote:
> On Oct 22 2007 22:16, Chris Wright wrote:
> >Yes, and I think we can still improve performance although I can't see
> >anyway to help out the modular case, so I guess it will have to incur
> >the hit that's always been there.
* Jan Engelhardt ([EMAIL PROTECTED]) wrote:
On Oct 22 2007 22:16, Chris Wright wrote:
Yes, and I think we can still improve performance although I can't see
anyway to help out the modular case, so I guess it will have to incur
the hit that's always been there. I think your Kconfig option
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
Chris Wright wrote:
Yes, and I think we can still improve performance although I can't see
anyway to help out the modular case, so I guess it will have to incur
the hit that's always been there.
Broaden the paravirt patching machinery
* Arjan van de Ven ([EMAIL PROTECTED]) wrote:
> On Sun, 21 Oct 2007 08:57:06 +1000 (EST)
> James Morris <[EMAIL PROTECTED]> wrote:
>
> > On Sat, 20 Oct 2007, Jan Engelhardt wrote:
> >
> > > >I'd like to note that I asked people who were actually affected,
> > > >and had examples of their
* Arjan van de Ven ([EMAIL PROTECTED]) wrote:
On Sun, 21 Oct 2007 08:57:06 +1000 (EST)
James Morris [EMAIL PROTECTED] wrote:
On Sat, 20 Oct 2007, Jan Engelhardt wrote:
I'd like to note that I asked people who were actually affected,
and had examples of their real-world use to step
* Serge E. Hallyn ([EMAIL PROTECTED]) wrote:
> Quoting Chris Wright ([EMAIL PROTECTED]):
> > * Serge E. Hallyn ([EMAIL PROTECTED]) wrote:
> > > I guess now that I've written this out, it seems pretty clear
> > > that capget64() and capget64() are the way to go. A
* Serge E. Hallyn ([EMAIL PROTECTED]) wrote:
Quoting Chris Wright ([EMAIL PROTECTED]):
* Serge E. Hallyn ([EMAIL PROTECTED]) wrote:
I guess now that I've written this out, it seems pretty clear
that capget64() and capget64() are the way to go. Any objections?
How is capget64
* Serge E. Hallyn ([EMAIL PROTECTED]) wrote:
> I guess now that I've written this out, it seems pretty clear
> that capget64() and capget64() are the way to go. Any objections?
How is capget64() different from capget() that supports 2 different
header->versions (I thought that was the whole
* Serge E. Hallyn ([EMAIL PROTECTED]) wrote:
I guess now that I've written this out, it seems pretty clear
that capget64() and capget64() are the way to go. Any objections?
How is capget64() different from capget() that supports 2 different
header-versions (I thought that was the whole point
* Oliver Pinter ([EMAIL PROTECTED]) wrote:
> it is Lepton's patch.
> Namesys boys, this patch is OK?
> Greg, I neither do find this patch in Linus's tree.
The point is, if it's not important enough to go into Linus' tree, than
it isn't important enough to be in the -stable tree. So please get
* Oliver Pinter ([EMAIL PROTECTED]) wrote:
it is Lepton's patch.
Namesys boys, this patch is OK?
Greg, I neither do find this patch in Linus's tree.
The point is, if it's not important enough to go into Linus' tree, than
it isn't important enough to be in the -stable tree. So please get this
diff --git a/Makefile b/Makefile
index 3067f6a..12edea0 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 22
-EXTRAVERSION = .6
+EXTRAVERSION = .7
NAME = Holy Dancing Manatees, Batman!
# *DOCUMENTATION*
diff --git a/arch/x86_64/ia32/ia32entry.S
(+), 8 deletions(-)
Summary of changes from v2.6.22.6 to v2.6.22.7
==
Andi Kleen (1):
x86_64: Zero extend all registers after ptrace in 32bit entry path.
Chris Wright (1):
Linux 2.6.22.7
-
To unsubscribe from this list: send the line
(+), 8 deletions(-)
Summary of changes from v2.6.22.6 to v2.6.22.7
==
Andi Kleen (1):
x86_64: Zero extend all registers after ptrace in 32bit entry path.
Chris Wright (1):
Linux 2.6.22.7
-
To unsubscribe from this list: send the line
diff --git a/Makefile b/Makefile
index 3067f6a..12edea0 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 22
-EXTRAVERSION = .6
+EXTRAVERSION = .7
NAME = Holy Dancing Manatees, Batman!
# *DOCUMENTATION*
diff --git a/arch/x86_64/ia32/ia32entry.S
* James Courtier-Dutton ([EMAIL PROTECTED]) wrote:
> Ok, so I need to get a new CPU like the Intel Core Duo that has VT
> features? I have an old Pentium 4 at the moment, without any VT features.
Depends on your goals. You can certainly give a paravirt Xen guest[1]
physical hardware without any
* James Courtier-Dutton ([EMAIL PROTECTED]) wrote:
> If one could directly expose a device to the guest, this feature could
> be extremely useful for me.
> Is it possible? How would it manage to handle the DMA bus mastering?
Yes it's possible (Xen supports pci pass through). Without an IOMMU
* Dave Jones ([EMAIL PROTECTED]) wrote:
> I have a reservation about voting for any of the above.
> Normally during any process involving votes, there exists some sort
> of "why you should vote for me" type statement. Does such a thing
> exist for this process ?
Last year each nominee made a
* Dave Jones ([EMAIL PROTECTED]) wrote:
I have a reservation about voting for any of the above.
Normally during any process involving votes, there exists some sort
of why you should vote for me type statement. Does such a thing
exist for this process ?
Last year each nominee made a statement
* James Courtier-Dutton ([EMAIL PROTECTED]) wrote:
If one could directly expose a device to the guest, this feature could
be extremely useful for me.
Is it possible? How would it manage to handle the DMA bus mastering?
Yes it's possible (Xen supports pci pass through). Without an IOMMU
(like
* James Courtier-Dutton ([EMAIL PROTECTED]) wrote:
Ok, so I need to get a new CPU like the Intel Core Duo that has VT
features? I have an old Pentium 4 at the moment, without any VT features.
Depends on your goals. You can certainly give a paravirt Xen guest[1]
physical hardware without any VT
should be
working fine right now with d34fda4a84c18402640a1a2342d6e6d9829e6db7
committed, and can be further refined with the patch below that's just
waiting on some further testing.
thanks,
-chris
--
Subject: [PATCH] x86: skip paravirt patching when appropriate
From: Chris Wright <[EMAIL
be
working fine right now with d34fda4a84c18402640a1a2342d6e6d9829e6db7
committed, and can be further refined with the patch below that's just
waiting on some further testing.
thanks,
-chris
--
Subject: [PATCH] x86: skip paravirt patching when appropriate
From: Chris Wright [EMAIL PROTECTED]
commit
* Chris Wright ([EMAIL PROTECTED]) wrote:
> Now that I understand the problem, I do have a very simple (slightly
> overkill) fix for paravirt patching. This can be cleaned up to avoid
> the copies when they aren't needed, but that will take a little more
> auditing of the vari
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
> On Sat, 18 Aug 2007, Chris Wright wrote:
> > >
> > > Check the latest git head. Does it still break?
> >
> > Yeah, this is the latest git. The broken commit is Rusty's patch which,
> > after Linus rev
* Andi Kleen ([EMAIL PROTECTED]) wrote:
> > This patch breaks Xen booting.
>
> Check the latest git head. Does it still break?
Yeah, this is the latest git. The broken commit is Rusty's patch which,
after Linus reverted the write-protected remap changes, is no longer
necessary. AFAICT
* Andi Kleen ([EMAIL PROTECTED]) wrote:
This patch breaks Xen booting.
Check the latest git head. Does it still break?
Yeah, this is the latest git. The broken commit is Rusty's patch which,
after Linus reverted the write-protected remap changes, is no longer
necessary. AFAICT patching
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
On Sat, 18 Aug 2007, Chris Wright wrote:
Check the latest git head. Does it still break?
Yeah, this is the latest git. The broken commit is Rusty's patch which,
after Linus reverted the write-protected remap changes, is no longer
* Chris Wright ([EMAIL PROTECTED]) wrote:
Now that I understand the problem, I do have a very simple (slightly
overkill) fix for paravirt patching. This can be cleaned up to avoid
the copies when they aren't needed, but that will take a little more
auditing of the various patchers. If you
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> This patch breaks Xen booting. I get infinite recursive faults during
> patching when this patch is present. If I boot with
> "noreplace-paravirt" it works OK, and it works as expected if I back
> this patch out. I haven't tracked down the
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
This patch breaks Xen booting. I get infinite recursive faults during
patching when this patch is present. If I boot with
noreplace-paravirt it works OK, and it works as expected if I back
this patch out. I haven't tracked down the exact
* Jeff Dike ([EMAIL PROTECTED]) wrote:
> [ This is both 2.6.24 and -stable material ]
>
> SuSE seems to require that binaries have a .note.SuSE section.
> Without it, UML segfaults if any parameters are passed on the command
> line.
Huh!? Why do we need a SuSE section?
thanks,
-chris
-
To
* Jeff Dike ([EMAIL PROTECTED]) wrote:
[ This is both 2.6.24 and -stable material ]
SuSE seems to require that binaries have a .note.SuSE section.
Without it, UML segfaults if any parameters are passed on the command
line.
Huh!? Why do we need a SuSE section?
thanks,
-chris
-
To
* Oleg Nesterov ([EMAIL PROTECTED]) wrote:
> On 08/03, Chris Wright wrote:
> >
> > +long do_restart_poll(struct restart_block *restart_block)
> > +{
> > + struct pollfd __user *ufds = (struct pollfd __user*)restart_block->arg0;
> > + int nfds = restart_bloc
* Glauber de Oliveira Costa ([EMAIL PROTECTED]) wrote:
> Only caveat, is that it has to be done before smp gets in the game, and
> with interrupts disabled. (which makes the function in vsmp.c not eligible).
>
> My current option is to force VSMP to use PARAVIRT, as said before, and
> then fill
* Glauber de Oliveira Costa ([EMAIL PROTECTED]) wrote:
> As alternatives what we have now, we can either keep the paravirt_ops as
> it is now for the native case, just hooking the vsmp functions in place
> of the normal one, (there are just three ops anyway), refill the
> paravirt_ops entirely
* Glauber de Oliveira Costa ([EMAIL PROTECTED]) wrote:
As alternatives what we have now, we can either keep the paravirt_ops as
it is now for the native case, just hooking the vsmp functions in place
of the normal one, (there are just three ops anyway), refill the
paravirt_ops entirely in
* Glauber de Oliveira Costa ([EMAIL PROTECTED]) wrote:
Only caveat, is that it has to be done before smp gets in the game, and
with interrupts disabled. (which makes the function in vsmp.c not eligible).
My current option is to force VSMP to use PARAVIRT, as said before, and
then fill
* Oleg Nesterov ([EMAIL PROTECTED]) wrote:
On 08/03, Chris Wright wrote:
+long do_restart_poll(struct restart_block *restart_block)
+{
+ struct pollfd __user *ufds = (struct pollfd __user*)restart_block-arg0;
+ int nfds = restart_block-arg1;
+ s64 timeout = ((s64)restart_block
* Randy Dunlap ([EMAIL PROTECTED]) wrote:
> On Mon, 13 Aug 2007 11:55:36 -0700 Chris Wright wrote:
> > * [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> > > +F: arch/i386/xen/
> > > +F: drivers/*/xen-*front.c
> > > +F: drivers/xen/
> >
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> Add file pattern to MAINTAINER entry
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e4e1cc3..8395aba 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5153,6 +5153,11 @@ M: [EMAIL
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> Add file pattern to MAINTAINER entry
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2166416..44768ce 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3519,6 +3519,9 @@ M: [EMAIL
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
Add file pattern to MAINTAINER entry
Signed-off-by: Joe Perches [EMAIL PROTECTED]
diff --git a/MAINTAINERS b/MAINTAINERS
index 2166416..44768ce 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3519,6 +3519,9 @@ M: [EMAIL PROTECTED]
L:
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
Add file pattern to MAINTAINER entry
Signed-off-by: Joe Perches [EMAIL PROTECTED]
diff --git a/MAINTAINERS b/MAINTAINERS
index e4e1cc3..8395aba 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5153,6 +5153,11 @@ M: [EMAIL PROTECTED]
L:
* Randy Dunlap ([EMAIL PROTECTED]) wrote:
On Mon, 13 Aug 2007 11:55:36 -0700 Chris Wright wrote:
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
+F: arch/i386/xen/
+F: drivers/*/xen-*front.c
+F: drivers/xen/
+F: include/asm-i386/xen/
+F: include/xen
s,
-chris
--
Subject: [PATCH] Use ERESTART_RESTARTBLOCK if poll() is interrupted by a signal
From: Chris Wright <[EMAIL PROTECTED]>
Lomesh reported poll returning EINTR during suspend/resume cycle.
This is caused by the STOP/CONT cycle that the freezer uses, generating
a pending signal for
--
Subject: [PATCH] Use ERESTART_RESTARTBLOCK if poll() is interrupted by a signal
From: Chris Wright [EMAIL PROTECTED]
Lomesh reported poll returning EINTR during suspend/resume cycle.
This is caused by the STOP/CONT cycle that the freezer uses, generating
a pending signal for what in effect
* Oleg Nesterov ([EMAIL PROTECTED]) wrote:
> > I am not sure. This means we restart sys_poll() with the same timeout
> > if there is no pending signal. I think we need ERESTART_RESTARTBLOCK
> > logic.
>
> Forgot to mention, sys_select() can use ERESTARTNOHAND because it
> modifies "struct timeval
* Oleg Nesterov ([EMAIL PROTECTED]) wrote:
I am not sure. This means we restart sys_poll() with the same timeout
if there is no pending signal. I think we need ERESTART_RESTARTBLOCK
logic.
Forgot to mention, sys_select() can use ERESTARTNOHAND because it
modifies struct timeval __user
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
> On Mon, 30 Jul 2007, Chris Wright wrote:
> > This also fixes paravirt patching which was broken when text_poke()
> > tried to patch the various pv ops in lookup_address.
>
> Hmm. What is "this"? The revert?
Yes
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
> On Thu, 26 Jul 2007, Rafael J. Wysocki wrote:
> > On my Turion64-based HPC nx6325 with the 2.6.23-rc1 x86_64 kernel doing
> >
> > # echo 0 > /sys/devices/system/cpu/cpu1/online
> >
> > causes the system to crash in a spectacular fashion (call traces
* Andrew Morton ([EMAIL PROTECTED]) wrote:
> On Sun, 29 Jul 2007 19:05:05 +0200 Manfred Spraul <[EMAIL PROTECTED]> wrote:
> > poll() returns -EINTR if a signal is pending.
> > EINTR is a bad choice: it means that poll returns to user space if the
> > task is stopped by SIGSTOP/SIGCONT or by the
* Manfred Spraul ([EMAIL PROTECTED]) wrote:
> poll() returns -EINTR if a signal is pending.
> EINTR is a bad choice: it means that poll returns to user space if the
> task is stopped by SIGSTOP/SIGCONT or by the freezer.
> select() and ppoll() both use ERESTARTNOHAND, this avoids a return to
>
* Manfred Spraul ([EMAIL PROTECTED]) wrote:
poll() returns -EINTR if a signal is pending.
EINTR is a bad choice: it means that poll returns to user space if the
task is stopped by SIGSTOP/SIGCONT or by the freezer.
select() and ppoll() both use ERESTARTNOHAND, this avoids a return to
user
* Andrew Morton ([EMAIL PROTECTED]) wrote:
On Sun, 29 Jul 2007 19:05:05 +0200 Manfred Spraul [EMAIL PROTECTED] wrote:
poll() returns -EINTR if a signal is pending.
EINTR is a bad choice: it means that poll returns to user space if the
task is stopped by SIGSTOP/SIGCONT or by the freezer.
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
On Thu, 26 Jul 2007, Rafael J. Wysocki wrote:
On my Turion64-based HPC nx6325 with the 2.6.23-rc1 x86_64 kernel doing
# echo 0 /sys/devices/system/cpu/cpu1/online
causes the system to crash in a spectacular fashion (call traces going
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
On Mon, 30 Jul 2007, Chris Wright wrote:
This also fixes paravirt patching which was broken when text_poke()
tried to patch the various pv ops in lookup_address.
Hmm. What is this? The revert?
Yes, sorry, your revert also fixes paravirt
* Pavel Machek ([EMAIL PROTECTED]) wrote:
> I believe there's still a lot that can be merged, and I'm responsible
> for some of it. Parts of suspend code should be shared, yet they are
> in differently named files in differently named directories.
>
> Ok, I guess I should fix it, arch/x86 or not.
* Pavel Machek ([EMAIL PROTECTED]) wrote:
I believe there's still a lot that can be merged, and I'm responsible
for some of it. Parts of suspend code should be shared, yet they are
in differently named files in differently named directories.
Ok, I guess I should fix it, arch/x86 or not.
* Matt Mackall ([EMAIL PROTECTED]) wrote:
> Can we see some stats on:
>
> How many files were auto-merged?
> How many files got 32.c and 64.c extensions?
> How many existed only in one arch?
It's mostly about file movement first.
Kbuild |8 +-
* Matt Mackall ([EMAIL PROTECTED]) wrote:
Can we see some stats on:
How many files were auto-merged?
How many files got 32.c and 64.c extensions?
How many existed only in one arch?
It's mostly about file movement first.
Kbuild |8 +-
* Glauber de Oliveira Costa ([EMAIL PROTECTED]) wrote:
> This patch provides a new set of functions for managing the descriptor
> tables that can be used instead of putting the raw assembly in .c files.
Looks alright, some cleanups below
> Remodeling of store_tr() suggested by Frederik Deweerdt.
* Rusty Russell ([EMAIL PROTECTED]) wrote:
> On Thu, 2007-07-19 at 09:27 +1000, Rusty Russell wrote:
> > On Wed, 2007-07-18 at 09:19 -0700, Zachary Amsden wrote:
> > > > +#define GET_CONTENTS(desc) (((desc)->raw32.b >> 10) & 3)
> > > > +#define GET_WRITABLE(desc) (((desc)->raw32.b >> 9) &
* Rusty Russell ([EMAIL PROTECTED]) wrote:
> Remove i386's Xgt_desc_struct definition and use desc_def.h's desc_ptr.
plus this is needed now
Index: linus-2.6/drivers/lguest/lg.h
===
--- linus-2.6.orig/drivers/lguest/lg.h
+++
* Rusty Russell ([EMAIL PROTECTED]) wrote:
On Thu, 2007-07-19 at 09:27 +1000, Rusty Russell wrote:
On Wed, 2007-07-18 at 09:19 -0700, Zachary Amsden wrote:
+#define GET_CONTENTS(desc) (((desc)-raw32.b 10) 3)
+#define GET_WRITABLE(desc) (((desc)-raw32.b 9) 1)
You got
* Rusty Russell ([EMAIL PROTECTED]) wrote:
Remove i386's Xgt_desc_struct definition and use desc_def.h's desc_ptr.
plus this is needed now
Index: linus-2.6/drivers/lguest/lg.h
===
--- linus-2.6.orig/drivers/lguest/lg.h
+++
* Glauber de Oliveira Costa ([EMAIL PROTECTED]) wrote:
This patch provides a new set of functions for managing the descriptor
tables that can be used instead of putting the raw assembly in .c files.
Looks alright, some cleanups below
Remodeling of store_tr() suggested by Frederik Deweerdt.
* Serge E. Hallyn ([EMAIL PROTECTED]) wrote:
> Actually, given that when lsm was being introduced, lsm seemed to
> improve performance overall, have you taken any measurements to show
> that this is actually the case? Of course it makes sense that it would,
> but witjout measurements we do not
* Serge E. Hallyn ([EMAIL PROTECTED]) wrote:
Actually, given that when lsm was being introduced, lsm seemed to
improve performance overall, have you taken any measurements to show
that this is actually the case? Of course it makes sense that it would,
but witjout measurements we do not know.
1 - 100 of 1959 matches
Mail list logo
