Re: [PATCH] maintainers: drop Chris Wright from pvops
(resend w/out html damage that triggers lkml reject) On Thu, Oct 26, 2017 at 3:17 PM, Rusty Russell <ru...@rustcorp.com.au> wrote: > Chris CC'd: He wasn't that hard to find. > > (linkedin says he's CTO of RedHat now. I feel like an underachiever!) > > Cheers, > Rusty. > > 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.com> ;) thanks, -chris >> --- >> MAINTAINERS | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index d85c08956875..af0cb69f6a3e 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -10179,7 +10179,6 @@ F:Documentation/parport*.txt >> >> PARAVIRT_OPS INTERFACE >> M: Juergen Gross <jgr...@suse.com> >> -M: Chris Wright <chr...@sous-sol.org> >> M: Alok Kataria <akata...@vmware.com> >> M: Rusty Russell <ru...@rustcorp.com.au> >> L: virtualizat...@lists.linux-foundation.org >> -- >> 2.12.3
Re: [PATCH] maintainers: drop Chris Wright from pvops
(resend w/out html damage that triggers lkml reject) On Thu, Oct 26, 2017 at 3:17 PM, Rusty Russell wrote: > Chris CC'd: He wasn't that hard to find. > > (linkedin says he's CTO of RedHat now. I feel like an underachiever!) > > Cheers, > Rusty. > > Juergen Gross writes: > >> 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, 1 deletion(-) >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index d85c08956875..af0cb69f6a3e 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -10179,7 +10179,6 @@ F: Documentation/parport*.txt >> >> PARAVIRT_OPS INTERFACE >> M: Juergen Gross >> -M: Chris Wright >> M: Alok Kataria >> M: Rusty Russell >> L: virtualizat...@lists.linux-foundation.org >> -- >> 2.12.3
Re: WARNING: at drivers/iommu/dmar.c:484 warn_invalid_dmar with Intel Motherboard
* 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 > > > > 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 have that disabled. I'll check it tonight. > > > > Did you find out if BIOS change fixed this? > > > No, it didn't. Enabling or disabling virtualization in the BIOS did not make > a difference. It looks like there is a bad DMAR table entry (with address 0) > in the ACPI data. In case you are interested how it looks like: > > DMAR @ 0xcb3f3f90 > : 44 4d 41 52 90 00 00 00 01 d5 49 4e 54 45 4c 20 DMAR..INTEL > 0010: 44 48 38 37 52 4c 20 20 40 01 00 00 49 4e 54 4c DH87RL @...INTL > 0020: 01 00 00 00 26 00 00 00 00 00 00 00 00 00 00 00 &... > 0030: 00 00 10 00 01 00 00 00 00 00 00 00 00 00 00 00 > 0040: 01 00 30 00 00 00 00 00 00 b0 eb cb 00 00 00 00 ..0. > 0050: ff 9f ec cb 00 00 00 00 01 08 00 00 00 00 1d 00 > 0060: 01 08 00 00 00 00 1a 00 01 08 00 00 00 00 14 00 > 0070: 01 00 20 00 00 00 00 00 00 00 00 d7 00 00 00 00 .. . > 0080: ff ff 1f df 00 00 00 00 01 08 00 00 00 00 02 00 > > Turns out the i7-4770K doesn't support VT-d, so my current understanding > is that there should be no DMAR table in the first place. OK, thanks for follow-up. You can see why the warnings are there now. This is your decoded DMAR table...has valid looking RMRR regions, and mostly valid looking DRHD (minus the invalid base address). /* * Intel ACPI Component Architecture * AML Disassembler version 20100528 * * Disassembly of /tmp/dmar, Thu Jul 11 15:24:28 2013 * * ACPI Data Table [DMAR] * * Format: [HexOffset DecimalOffset ByteLength] FieldName : FieldValue */ [000h 4]Signature : "DMAR"/* DMA Remapping table */ [004h 0004 4] Table Length : 0090 [008h 0008 1] Revision : 01 [009h 0009 1] Checksum : D5 [00Ah 0010 6] Oem ID : "INTEL " [010h 0016 8] Oem Table ID : "DH87RL " [018h 0024 4] Oem Revision : 0140 [01Ch 0028 4] Asl Compiler ID : "INTL" [020h 0032 4]Asl Compiler Revision : 0001 [024h 0036 1] Host Address Width : 26 [025h 0037 1]Flags : 00 [030h 0048 2]Subtable Type : [032h 0050 2] Length : 0010 [034h 0052 1]Flags : 01 [035h 0053 1] Reserved : 00 [036h 0054 2] PCI Segment Number : [038h 0056 8]Register Base Address : [040h 0064 2]Subtable Type : 0001 [042h 0066 2] Length : 0030 [044h 0068 2] Reserved : [046h 0070 2] PCI Segment Number : [048h 0072 8] Base Address : CBEBB000 [050h 0080 8] End Address (limit) : CBEC9FFF [058h 0088 1] Device Scope Entry Type : 01 [059h 0089 1] Entry Length : 08 [05Ah 0090 2] Reserved : [05Ch 0092 1] Enumeration ID : 00 [05Dh 0093 1] PCI Bus Number : 00 [05Eh 0094 2] PCI Path : [1D, 00] [060h 0096 1] Device Scope Entry Type : 01 [061h 0097 1] Entry Length : 08 [062h 0098 2] Reserved : [064h 0100 1] Enumeration ID : 00 [065h 0101 1] PCI Bus Number : 00 [066h 0102 2] PCI Path : [1A, 00] [068h 0104 1] Device Scope Entry Type : 01 [069h 0105 1] Entry Length : 08 [06Ah 0106 2] Reserved : [06Ch 0108 1] Enumeration ID : 00 [06Dh 0109 1] PCI Bus Number : 00 [06Eh 0110 2] PCI Path : [14, 00] [070h 0112 2]Subtable Type : 0001 [072h 0114 2] Length : 0020 [074h 0116 2] Reserved : [076h 0118 2] PCI Segment Number : [078h 0120 8] Base Address : D700 [080h 0128 8] End Address (limit) : DF1F [088h 0136 1] Device Scope Entry Type : 01 [089h 0137 1] Entry Length : 08 [08Ah 0138 2] Reserved : [08Ch 0140 1] Enumeration ID : 00 [08Dh 0141 1] PCI Bus Num
Re: WARNING: at drivers/iommu/dmar.c:484 warn_invalid_dmar with Intel Motherboard
* 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 have that disabled. I'll check it tonight. Did you find out if BIOS change fixed this? thanks, -chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: at drivers/iommu/dmar.c:484 warn_invalid_dmar with Intel Motherboard
* 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 have that disabled. I'll check it tonight. Did you find out if BIOS change fixed this? thanks, -chris -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: at drivers/iommu/dmar.c:484 warn_invalid_dmar with Intel Motherboard
* 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 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 have that disabled. I'll check it tonight. Did you find out if BIOS change fixed this? No, it didn't. Enabling or disabling virtualization in the BIOS did not make a difference. It looks like there is a bad DMAR table entry (with address 0) in the ACPI data. In case you are interested how it looks like: DMAR @ 0xcb3f3f90 : 44 4d 41 52 90 00 00 00 01 d5 49 4e 54 45 4c 20 DMAR..INTEL 0010: 44 48 38 37 52 4c 20 20 40 01 00 00 49 4e 54 4c DH87RL @...INTL 0020: 01 00 00 00 26 00 00 00 00 00 00 00 00 00 00 00 ... 0030: 00 00 10 00 01 00 00 00 00 00 00 00 00 00 00 00 0040: 01 00 30 00 00 00 00 00 00 b0 eb cb 00 00 00 00 ..0. 0050: ff 9f ec cb 00 00 00 00 01 08 00 00 00 00 1d 00 0060: 01 08 00 00 00 00 1a 00 01 08 00 00 00 00 14 00 0070: 01 00 20 00 00 00 00 00 00 00 00 d7 00 00 00 00 .. . 0080: ff ff 1f df 00 00 00 00 01 08 00 00 00 00 02 00 Turns out the i7-4770K doesn't support VT-d, so my current understanding is that there should be no DMAR table in the first place. OK, thanks for follow-up. You can see why the warnings are there now. This is your decoded DMAR table...has valid looking RMRR regions, and mostly valid looking DRHD (minus the invalid base address). /* * Intel ACPI Component Architecture * AML Disassembler version 20100528 * * Disassembly of /tmp/dmar, Thu Jul 11 15:24:28 2013 * * ACPI Data Table [DMAR] * * Format: [HexOffset DecimalOffset ByteLength] FieldName : FieldValue */ [000h 4]Signature : DMAR/* DMA Remapping table */ [004h 0004 4] Table Length : 0090 [008h 0008 1] Revision : 01 [009h 0009 1] Checksum : D5 [00Ah 0010 6] Oem ID : INTEL [010h 0016 8] Oem Table ID : DH87RL [018h 0024 4] Oem Revision : 0140 [01Ch 0028 4] Asl Compiler ID : INTL [020h 0032 4]Asl Compiler Revision : 0001 [024h 0036 1] Host Address Width : 26 [025h 0037 1]Flags : 00 [030h 0048 2]Subtable Type : Hardware Unit Definition [032h 0050 2] Length : 0010 [034h 0052 1]Flags : 01 [035h 0053 1] Reserved : 00 [036h 0054 2] PCI Segment Number : [038h 0056 8]Register Base Address : [040h 0064 2]Subtable Type : 0001 Reserved Memory Region [042h 0066 2] Length : 0030 [044h 0068 2] Reserved : [046h 0070 2] PCI Segment Number : [048h 0072 8] Base Address : CBEBB000 [050h 0080 8] End Address (limit) : CBEC9FFF [058h 0088 1] Device Scope Entry Type : 01 [059h 0089 1] Entry Length : 08 [05Ah 0090 2] Reserved : [05Ch 0092 1] Enumeration ID : 00 [05Dh 0093 1] PCI Bus Number : 00 [05Eh 0094 2] PCI Path : [1D, 00] [060h 0096 1] Device Scope Entry Type : 01 [061h 0097 1] Entry Length : 08 [062h 0098 2] Reserved : [064h 0100 1] Enumeration ID : 00 [065h 0101 1] PCI Bus Number : 00 [066h 0102 2] PCI Path : [1A, 00] [068h 0104 1] Device Scope Entry Type : 01 [069h 0105 1] Entry Length : 08 [06Ah 0106 2] Reserved : [06Ch 0108 1] Enumeration ID : 00 [06Dh 0109 1] PCI Bus Number : 00 [06Eh 0110 2] PCI Path : [14, 00] [070h 0112 2]Subtable Type : 0001 Reserved Memory Region [072h 0114 2] Length : 0020 [074h 0116 2] Reserved : [076h 0118 2] PCI Segment Number : [078h 0120 8] Base Address : D700 [080h 0128 8] End Address (limit) : DF1F [088h 0136 1] Device Scope Entry Type : 01 [089h 0137 1] Entry Length : 08 [08Ah 0138 2] Reserved : [08Ch 0140 1] Enumeration ID : 00 [08Dh 0141 1] PCI Bus Number : 00 [08Eh 0142 2] PCI Path : [02, 00] Raw Table Data : 44 4D 41 52 90 00 00 00 01 D5 49 4E 54 45 4C 20 DMAR..INTEL 0010: 44 48 38 37 52 4C 20 20 40
Re: WARNING: at drivers/iommu/dmar.c:484 warn_invalid_dmar with Intel Motherboard
* 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, Guenter Roeck > > > > wrote: > > > > > I started seeing this problem after updating the BIOS trying fix > > > > > another issue, > > > > > though I may have missed it earlier. > > > > > > > > > > I understand this is a BIOS bug. Would be great if someone can pass > > > > > this on > > > > > to Intel BIOS engineers. > > > > > > > > Maybe. It'd be nice if Linux handled it better, though. > > > > > > > If anyone has an idea how to do that, I'll be happy to write a patch. > > > > I'm not sure there's much you can do. The BIOS is saying there's a DMAR > > unit, and then saying the registers are at addr 0x0. The kernel is > > simply warning you about the invalid DMAR table entry. > > > > 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 have that disabled. I'll check it tonight. > > Does that really warrant a traceback, or would a warning message be more > appropriate (possibly telling the user to enable VT-d) ? Bottom line, the BIOS is providing what we're seeing as invalid tables. If it's a BIOS attempt to disable VT-d is hard to glean from invalid tables, and not all BIOS give interface to enable/disable VT-d. It is a warning message, BTW. Guess I'd be inclined to leave as it is. thanks, -chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: at drivers/iommu/dmar.c:484 warn_invalid_dmar with Intel Motherboard
* 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 > > > issue, > > > though I may have missed it earlier. > > > > > > I understand this is a BIOS bug. Would be great if someone can pass this > > > on > > > to Intel BIOS engineers. > > > > Maybe. It'd be nice if Linux handled it better, though. > > > If anyone has an idea how to do that, I'll be happy to write a patch. I'm not sure there's much you can do. The BIOS is saying there's a DMAR unit, and then saying the registers are at addr 0x0. The kernel is simply warning you about the invalid DMAR table entry. 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. thanks, -chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: at drivers/iommu/dmar.c:484 warn_invalid_dmar with Intel Motherboard
* 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 issue, though I may have missed it earlier. I understand this is a BIOS bug. Would be great if someone can pass this on to Intel BIOS engineers. Maybe. It'd be nice if Linux handled it better, though. If anyone has an idea how to do that, I'll be happy to write a patch. I'm not sure there's much you can do. The BIOS is saying there's a DMAR unit, and then saying the registers are at addr 0x0. The kernel is simply warning you about the invalid DMAR table entry. 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. thanks, -chris -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: at drivers/iommu/dmar.c:484 warn_invalid_dmar with Intel Motherboard
* 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, Guenter Roeck li...@roeck-us.net wrote: I started seeing this problem after updating the BIOS trying fix another issue, though I may have missed it earlier. I understand this is a BIOS bug. Would be great if someone can pass this on to Intel BIOS engineers. Maybe. It'd be nice if Linux handled it better, though. If anyone has an idea how to do that, I'll be happy to write a patch. I'm not sure there's much you can do. The BIOS is saying there's a DMAR unit, and then saying the registers are at addr 0x0. The kernel is simply warning you about the invalid DMAR table entry. 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 have that disabled. I'll check it tonight. Does that really warrant a traceback, or would a warning message be more appropriate (possibly telling the user to enable VT-d) ? Bottom line, the BIOS is providing what we're seeing as invalid tables. If it's a BIOS attempt to disable VT-d is hard to glean from invalid tables, and not all BIOS give interface to enable/disable VT-d. It is a warning message, BTW. Guess I'd be inclined to leave as it is. thanks, -chris -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] debugfs: make __create_file static
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/debugfs/inode.c
@@ -291,9 +291,9 @@ static struct file_system_type debug_fs_type = {
.kill_sb = kill_litter_super,
};
-struct dentry *__create_file(const char *name, umode_t mode,
- struct dentry *parent, void *data,
- const struct file_operations *fops)
+static struct dentry *__create_file(const char *name, umode_t mode,
+ struct dentry *parent, void *data,
+ const struct file_operations *fops)
{
struct dentry *dentry = NULL;
int error;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] debugfs: make __create_file static
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/inode.c
+++ b/fs/debugfs/inode.c
@@ -291,9 +291,9 @@ static struct file_system_type debug_fs_type = {
.kill_sb = kill_litter_super,
};
-struct dentry *__create_file(const char *name, umode_t mode,
- struct dentry *parent, void *data,
- const struct file_operations *fops)
+static struct dentry *__create_file(const char *name, umode_t mode,
+ struct dentry *parent, void *data,
+ const struct file_operations *fops)
{
struct dentry *dentry = NULL;
int error;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: {2.6.22.y} CVE-2007-6434
* 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 specifically crafted binary do_brk() can be used to get low pages > available in userspace virtual memory and can thus be used to circumvent > the mmap_min_addr low memory protection. Add security checks in do_brk(). All of the low mmap addr stuff isn't added until 2.6.23. thanks, -chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: {2.6.22.y} CVE-2007-6434
* 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 specifically crafted binary do_brk() can be used to get low pages available in userspace virtual memory and can thus be used to circumvent the mmap_min_addr low memory protection. Add security checks in do_brk(). All of the low mmap addr stuff isn't added until 2.6.23. thanks, -chris -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/10] add missing parameter for lookup_address
* 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 CONFIG_EFI=y -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/10] add missing parameter for lookup_address
* 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 CONFIG_EFI=y -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86: refactor ioport unification
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 PROTECTED]>
---
Applies atop the ioport unification fix for 32-bit
arch/x86/kernel/ioport.c | 40 +---
1 files changed, 21 insertions(+), 19 deletions(-)
diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c
index be72d80..50e5e4a 100644
--- a/arch/x86/kernel/ioport.c
+++ b/arch/x86/kernel/ioport.c
@@ -113,13 +113,9 @@ asmlinkage long sys_ioperm(unsigned long from, unsigned
long num, int turn_on)
* on system-call entry - see also fork() and the signal handling
* code.
*/
-#ifdef CONFIG_X86_32
-asmlinkage long sys_iopl(unsigned long regsp)
+static int do_iopl(unsigned int level, struct pt_regs *regs)
{
- struct pt_regs *regs = (struct pt_regs *)
- unsigned int level = regs->bx;
unsigned int old = (regs->flags >> 12) & 3;
- struct thread_struct *t = >thread;
if (level > 3)
return -EINVAL;
@@ -128,25 +124,31 @@ asmlinkage long sys_iopl(unsigned long regsp)
if (!capable(CAP_SYS_RAWIO))
return -EPERM;
}
- t->iopl = level << 12;
regs->flags = (regs->flags & ~X86_EFLAGS_IOPL) | (level << 12);
- set_iopl_mask(t->iopl);
+
return 0;
}
-#else
-asmlinkage long sys_iopl(unsigned int level, struct pt_regs *regs)
+
+#ifdef CONFIG_X86_32
+asmlinkage long sys_iopl(unsigned long regsp)
{
- unsigned int old = (regs->flags >> 12) & 3;
+ struct pt_regs *regs = (struct pt_regs *)
+ unsigned int level = regs->bx;
+ struct thread_struct *t = >thread;
+ int rc;
- if (level > 3)
- return -EINVAL;
- /* Trying to gain more privileges? */
- if (level > old) {
- if (!capable(CAP_SYS_RAWIO))
- return -EPERM;
- }
- regs->flags = (regs->flags & ~X86_EFLAGS_IOPL) | (level << 12);
+ rc = do_iopl(level, regs);
+ if (rc < 0)
+ goto out;
- return 0;
+ t->iopl = level << 12;
+ set_iopl_mask(t->iopl);
+out:
+ return rc;
+}
+#else
+asmlinkage long sys_iopl(unsigned int level, struct pt_regs *regs)
+{
+ return do_iopl(level, regs);
}
#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86: fix ioport unification on 32-bit [was: Re: hwclock failure in x86.git]
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
> thanks for tracking it down. I pulled that commit for now. But it would
> be nice to figure out what's going on there.
Zach was right. The unification was broken for 32-bit; it was missing
the actual pushf/popf EFLAGS manipluation (set_iopl_mask()) and would've
broken task switching between processes w/ different iopl in paravirt
guests too. 64-bit sys_iopl just does pt_regs->flags modification and
lets syscall/sysret plus ptregscall sync and do EFLAGS update.
Also, use of volatile looks like leftover cruft.
This patch in on top of 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] x86: fix ioport unification on 32-bit
ioport unification was broken for 32-bit; it was missing
the acutal pushf/popf EFLAGS manipulation (set_iopl_mask()).
Also, use of volatile looks like leftover cruft.
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 PROTECTED]>
---
arch/x86/kernel/ioport.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c
index e723ff3..be72d80 100644
--- a/arch/x86/kernel/ioport.c
+++ b/arch/x86/kernel/ioport.c
@@ -116,9 +116,10 @@ asmlinkage long sys_ioperm(unsigned long from, unsigned
long num, int turn_on)
#ifdef CONFIG_X86_32
asmlinkage long sys_iopl(unsigned long regsp)
{
- volatile struct pt_regs *regs = (struct pt_regs *)
+ struct pt_regs *regs = (struct pt_regs *)
unsigned int level = regs->bx;
unsigned int old = (regs->flags >> 12) & 3;
+ struct thread_struct *t = >thread;
if (level > 3)
return -EINVAL;
@@ -127,8 +128,9 @@ asmlinkage long sys_iopl(unsigned long regsp)
if (!capable(CAP_SYS_RAWIO))
return -EPERM;
}
+ t->iopl = level << 12;
regs->flags = (regs->flags & ~X86_EFLAGS_IOPL) | (level << 12);
-
+ set_iopl_mask(t->iopl);
return 0;
}
#else
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86: refactor ioport unification
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 PROTECTED]
---
Applies atop the ioport unification fix for 32-bit
arch/x86/kernel/ioport.c | 40 +---
1 files changed, 21 insertions(+), 19 deletions(-)
diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c
index be72d80..50e5e4a 100644
--- a/arch/x86/kernel/ioport.c
+++ b/arch/x86/kernel/ioport.c
@@ -113,13 +113,9 @@ asmlinkage long sys_ioperm(unsigned long from, unsigned
long num, int turn_on)
* on system-call entry - see also fork() and the signal handling
* code.
*/
-#ifdef CONFIG_X86_32
-asmlinkage long sys_iopl(unsigned long regsp)
+static int do_iopl(unsigned int level, struct pt_regs *regs)
{
- struct pt_regs *regs = (struct pt_regs *)regsp;
- unsigned int level = regs-bx;
unsigned int old = (regs-flags 12) 3;
- struct thread_struct *t = current-thread;
if (level 3)
return -EINVAL;
@@ -128,25 +124,31 @@ asmlinkage long sys_iopl(unsigned long regsp)
if (!capable(CAP_SYS_RAWIO))
return -EPERM;
}
- t-iopl = level 12;
regs-flags = (regs-flags ~X86_EFLAGS_IOPL) | (level 12);
- set_iopl_mask(t-iopl);
+
return 0;
}
-#else
-asmlinkage long sys_iopl(unsigned int level, struct pt_regs *regs)
+
+#ifdef CONFIG_X86_32
+asmlinkage long sys_iopl(unsigned long regsp)
{
- unsigned int old = (regs-flags 12) 3;
+ struct pt_regs *regs = (struct pt_regs *)regsp;
+ unsigned int level = regs-bx;
+ struct thread_struct *t = current-thread;
+ int rc;
- if (level 3)
- return -EINVAL;
- /* Trying to gain more privileges? */
- if (level old) {
- if (!capable(CAP_SYS_RAWIO))
- return -EPERM;
- }
- regs-flags = (regs-flags ~X86_EFLAGS_IOPL) | (level 12);
+ rc = do_iopl(level, regs);
+ if (rc 0)
+ goto out;
- return 0;
+ t-iopl = level 12;
+ set_iopl_mask(t-iopl);
+out:
+ return rc;
+}
+#else
+asmlinkage long sys_iopl(unsigned int level, struct pt_regs *regs)
+{
+ return do_iopl(level, regs);
}
#endif
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86: fix ioport unification on 32-bit [was: Re: hwclock failure in x86.git]
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
thanks for tracking it down. I pulled that commit for now. But it would
be nice to figure out what's going on there.
Zach was right. The unification was broken for 32-bit; it was missing
the actual pushf/popf EFLAGS manipluation (set_iopl_mask()) and would've
broken task switching between processes w/ different iopl in paravirt
guests too. 64-bit sys_iopl just does pt_regs-flags modification and
lets syscall/sysret plus ptregscall sync and do EFLAGS update.
Also, use of volatile looks like leftover cruft.
This patch in on top of Miguel's (can 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 unification on 32-bit
ioport unification was broken for 32-bit; it was missing
the acutal pushf/popf EFLAGS manipulation (set_iopl_mask()).
Also, use of volatile looks like leftover cruft.
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 PROTECTED]
---
arch/x86/kernel/ioport.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c
index e723ff3..be72d80 100644
--- a/arch/x86/kernel/ioport.c
+++ b/arch/x86/kernel/ioport.c
@@ -116,9 +116,10 @@ asmlinkage long sys_ioperm(unsigned long from, unsigned
long num, int turn_on)
#ifdef CONFIG_X86_32
asmlinkage long sys_iopl(unsigned long regsp)
{
- volatile struct pt_regs *regs = (struct pt_regs *)regsp;
+ struct pt_regs *regs = (struct pt_regs *)regsp;
unsigned int level = regs-bx;
unsigned int old = (regs-flags 12) 3;
+ struct thread_struct *t = current-thread;
if (level 3)
return -EINVAL;
@@ -127,8 +128,9 @@ asmlinkage long sys_iopl(unsigned long regsp)
if (!capable(CAP_SYS_RAWIO))
return -EPERM;
}
+ t-iopl = level 12;
regs-flags = (regs-flags ~X86_EFLAGS_IOPL) | (level 12);
-
+ set_iopl_mask(t-iopl);
return 0;
}
#else
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 01/11] Add basic support for gcc profiler instrumentation
* 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 > > is now always on for i386. Since MCOUNT disables REGPARM the calling > > convention changes (caller pushes to stack, callee expects register) > > chaos ensues. I sent a patch to fix that quite some months back, but > > it went stale and I neglected to update it. Would you like me to dig > > it up refresh and resend? > > Chris, thanks for the refresher. > > I'm going to see if we can remove the REGPARM hack and change the way > mcount does its calls. Maybe this will fix things for us. I don't recall why mcount disables regparm, but I think you're on the right path to remove that dependency. thanks, -chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 01/11] Add basic support for gcc profiler instrumentation
* 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 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 is now always on for i386. Since MCOUNT disables REGPARM the calling convention changes (caller pushes to stack, callee expects register) chaos ensues. I sent a patch to fix that quite some months back, but it went stale and I neglected to update it. Would you like me to dig it up refresh and resend? thanks, -chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 01/11] Add basic support for gcc profiler instrumentation
* 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 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 is now always on for i386. Since MCOUNT disables REGPARM the calling convention changes (caller pushes to stack, callee expects register) chaos ensues. I sent a patch to fix that quite some months back, but it went stale and I neglected to update it. Would you like me to dig it up refresh and resend? thanks, -chris -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 01/11] Add basic support for gcc profiler instrumentation
* 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 is now always on for i386. Since MCOUNT disables REGPARM the calling convention changes (caller pushes to stack, callee expects register) chaos ensues. I sent a patch to fix that quite some months back, but it went stale and I neglected to update it. Would you like me to dig it up refresh and resend? Chris, thanks for the refresher. I'm going to see if we can remove the REGPARM hack and change the way mcount does its calls. Maybe this will fix things for us. I don't recall why mcount disables regparm, but I think you're on the right path to remove that dependency. thanks, -chris -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] audit: clear thread flag for new children
* Tony Jones ([EMAIL PROTECTED]) wrote: > From: Tony Jones <[EMAIL PROTECTED]> > Minor performance enhancement. > > Thread flag TIF_SYSCALL_AUDIT is not cleared for new children when audit > context creation has been disabled (auditctl -e0). This can cause new > children > 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 <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] audit: clear thread flag for new children
* Tony Jones ([EMAIL PROTECTED]) wrote: From: Tony Jones [EMAIL PROTECTED] Minor performance enhancement. Thread flag TIF_SYSCALL_AUDIT is not cleared for new children when audit context creation has been disabled (auditctl -e0). This can cause new children 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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
* 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 and James, despite their clear bias towards SELinux, do try to give good feedback. But you are right, there's not enough active help for people trying to make a contribution to get their code in shape. Many of the modules that come along have been misguided conceptually, but I think that e.g. apparmor, tomoyo, smack could use that kind of constructive help to get into final mergable shape. Personally, I haven't spent nearly enough time reviewing those, my apologies to those developers. So, yes, help is welcome. thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
* 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 innovation is critical to the success of Linux, and security is not immune to that. The trouble is that most of the security modules that have come forward have had some real serious shortcomings. I do believe it is prudent to keep in-tree security sensitive code under high scrutiny because we do not want to create security holes by adding problematic security code. thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
* 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 innovation is critical to the success of Linux, and security is not immune to that. The trouble is that most of the security modules that have come forward have had some real serious shortcomings. I do believe it is prudent to keep in-tree security sensitive code under high scrutiny because we do not want to create security holes by adding problematic security code. thanks, -chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
* 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 and James, despite their clear bias towards SELinux, do try to give good feedback. But you are right, there's not enough active help for people trying to make a contribution to get their code in shape. Many of the modules that come along have been misguided conceptually, but I think that e.g. apparmor, tomoyo, smack could use that kind of constructive help to get into final mergable shape. Personally, I haven't spent nearly enough time reviewing those, my apologies to those developers. So, yes, help is welcome. thanks, -chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LSM conversion to static interface [revert patch]
* 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? Yup, that's essentially what we've been talking about. thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LSM conversion to static interface [revert patch]
* 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 is a > >decent compromise. > > (Un)registering security modules is a one-time hit. You do not load > and unload modules on a per-minute basis outside debugging. I'm referring to the hit for indirect calls - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LSM conversion to static interface [revert patch]
* 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 is a decent compromise. (Un)registering security modules is a one-time hit. You do not load and unload modules on a per-minute basis outside debugging. I'm referring to the hit for indirect calls - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LSM conversion to static interface [revert patch]
* 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? Yup, that's essentially what we've been talking about. thanks, -chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LSM conversion to static interface [revert patch]
* 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 forward and > > > >explain their use, and that I explicitly mentioned that this is > > > >something we can easily re-visit. > > > > > > > > > > I do have a pseudo LSM called "multiadm" at > > > http://freshmeat.net/p/multiadm/ , quoting: > > > > > > > Based on Linus' criteria, this appears to be a case for reverting the > > static LSM patch. > > I don't want to argue for or against the actual revert; however if > Linus/James/Chris > decide to do a revert, I've made a patch to do that below Thanks Arjan. I did not actually oppose making it non-modular, and thought there was sufficient time for people to complain meaningfully on that change. I also think there's not a lot of value in the modular interface, but it's very difficult to have rational discussions in this area. > (doing a full git revert is tricky since it gets mixed up with various other > cleanup > patches; even inside the original patch. I've done the relevant pieces by > hand via a > selective patch -R and compile-tested it). In addition I've made the > modularity a > Kconfig option, since it's clearly something that is contested and thus is > justified > as a user compile time choice; people who don't want this (out of paranoia or > otherwise) > can now decide to disable, while others who want to experiment or use out of > tree > LSM modules, can select the KConfig option. > > If it turns out that the above module becomes unmaintained and no longer > usable, and no > other useful cases show up, we can always garbage collect this code in the > future; it's > now low-overhead anyway for those who care, due to the KConfig option. 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 is a decent compromise. thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LSM conversion to static interface [revert patch]
* 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 forward and explain their use, and that I explicitly mentioned that this is something we can easily re-visit. I do have a pseudo LSM called multiadm at http://freshmeat.net/p/multiadm/ , quoting: Based on Linus' criteria, this appears to be a case for reverting the static LSM patch. I don't want to argue for or against the actual revert; however if Linus/James/Chris decide to do a revert, I've made a patch to do that below Thanks Arjan. I did not actually oppose making it non-modular, and thought there was sufficient time for people to complain meaningfully on that change. I also think there's not a lot of value in the modular interface, but it's very difficult to have rational discussions in this area. (doing a full git revert is tricky since it gets mixed up with various other cleanup patches; even inside the original patch. I've done the relevant pieces by hand via a selective patch -R and compile-tested it). In addition I've made the modularity a Kconfig option, since it's clearly something that is contested and thus is justified as a user compile time choice; people who don't want this (out of paranoia or otherwise) can now decide to disable, while others who want to experiment or use out of tree LSM modules, can select the KConfig option. If it turns out that the above module becomes unmaintained and no longer usable, and no other useful cases show up, we can always garbage collect this code in the future; it's now low-overhead anyway for those who care, due to the KConfig option. 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 is a decent compromise. thanks, -chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities
* 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() different from capget() that supports 2 different > > header->versions (I thought that was the whole point of the versioned, > > rather opaque interface)? I don't object to a new syscall, but I don't > > see why it's required to avoid breaking libcap. > > Hmm, I guess it *works*, it's just harder to explain the "inconsistent" > behavior. Now instead of saying "capget() will fail under certain > conditions while capget64() will always succeed", capget() will actually > fail under certain conditions only if you send in a certain header. > > Again, once I've written it out, I guess it isn't *so* bad. It's not really any different than issuing capget(0x19980330) (assuming capget64 is different), and getting -EINVAL when the actual in-use caps are > 32 bits wide. In either case the rules are the same -- old interface works fine as long as you don't have new caps involved. Only advantage I see to using the extant interface is that the cap[sg]et interface is already designed to be future-proof (albeit in an unusual way compared with most other kernel syscalls). thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities
* 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() different from capget() that supports 2 different header-versions (I thought that was the whole point of the versioned, rather opaque interface)? I don't object to a new syscall, but I don't see why it's required to avoid breaking libcap. Hmm, I guess it *works*, it's just harder to explain the inconsistent behavior. Now instead of saying capget() will fail under certain conditions while capget64() will always succeed, capget() will actually fail under certain conditions only if you send in a certain header. Again, once I've written it out, I guess it isn't *so* bad. It's not really any different than issuing capget(0x19980330) (assuming capget64 is different), and getting -EINVAL when the actual in-use caps are 32 bits wide. In either case the rules are the same -- old interface works fine as long as you don't have new caps involved. Only advantage I see to using the extant interface is that the cap[sg]et interface is already designed to be future-proof (albeit in an unusual way compared with most other kernel syscalls). thanks, -chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities
* 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 of the versioned, rather opaque interface)? I don't object to a new syscall, but I don't see why it's required to avoid breaking libcap. thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities
* 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 of the versioned, rather opaque interface)? I don't object to a new syscall, but I don't see why it's required to avoid breaking libcap. thanks, -chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] [PATCH] 2.6.22.6 fix kernel panic on corrupted reiserfs directory
* 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 patch upstream to Linus, then we will take it for -stable. thanks, -chris P.S. When forwarding someone else's patch, always include the proper authorship (such as "From: Lepton Wu <[EMAIL PROTECTED]>" in the first line of the email body) so that information is not lost. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] [PATCH] 2.6.22.6 fix kernel panic on corrupted reiserfs directory
* 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 patch upstream to Linus, then we will take it for -stable. thanks, -chris P.S. When forwarding someone else's patch, always include the proper authorship (such as From: Lepton Wu [EMAIL PROTECTED] in the first line of the email body) so that information is not lost. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.22.7
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 b/arch/x86_64/ia32/ia32entry.S
index 47565c3..0bc623a 100644
--- a/arch/x86_64/ia32/ia32entry.S
+++ b/arch/x86_64/ia32/ia32entry.S
@@ -38,6 +38,18 @@
movq%rax,R8(%rsp)
.endm
+ .macro LOAD_ARGS32 offset
+ movl \offset(%rsp),%r11d
+ movl \offset+8(%rsp),%r10d
+ movl \offset+16(%rsp),%r9d
+ movl \offset+24(%rsp),%r8d
+ movl \offset+40(%rsp),%ecx
+ movl \offset+48(%rsp),%edx
+ movl \offset+56(%rsp),%esi
+ movl \offset+64(%rsp),%edi
+ movl \offset+72(%rsp),%eax
+ .endm
+
.macro CFI_STARTPROC32 simple
CFI_STARTPROC \simple
CFI_UNDEFINED r8
@@ -152,7 +164,7 @@ sysenter_tracesys:
movq$-ENOSYS,RAX(%rsp) /* really needed? */
movq%rsp,%rdi/* _regs -> arg1 */
callsyscall_trace_enter
- LOAD_ARGS ARGOFFSET /* reload args from stack in case ptrace changed
it */
+ LOAD_ARGS32 ARGOFFSET /* reload args from stack in case ptrace changed
it */
RESTORE_REST
movl%ebp, %ebp
/* no need to do an access_ok check here because rbp has been
@@ -255,7 +267,7 @@ cstar_tracesys:
movq $-ENOSYS,RAX(%rsp) /* really needed? */
movq %rsp,%rdi/* _regs -> arg1 */
call syscall_trace_enter
- LOAD_ARGS ARGOFFSET /* reload args from stack in case ptrace changed
it */
+ LOAD_ARGS32 ARGOFFSET /* reload args from stack in case ptrace changed
it */
RESTORE_REST
movl RSP-ARGOFFSET(%rsp), %r8d
/* no need to do an access_ok check here because r8 has been
@@ -333,7 +345,7 @@ ia32_tracesys:
movq $-ENOSYS,RAX(%rsp) /* really needed? */
movq %rsp,%rdi/* _regs -> arg1 */
call syscall_trace_enter
- LOAD_ARGS ARGOFFSET /* reload args from stack in case ptrace changed
it */
+ LOAD_ARGS32 ARGOFFSET /* reload args from stack in case ptrace changed
it */
RESTORE_REST
jmp ia32_do_syscall
END(ia32_syscall)
diff --git a/arch/x86_64/kernel/ptrace.c b/arch/x86_64/kernel/ptrace.c
index 9409117..8d89d8c 100644
--- a/arch/x86_64/kernel/ptrace.c
+++ b/arch/x86_64/kernel/ptrace.c
@@ -223,10 +223,6 @@ static int putreg(struct task_struct *child,
{
unsigned long tmp;
- /* Some code in the 64bit emulation may not be 64bit clean.
- Don't take any chances. */
- if (test_tsk_thread_flag(child, TIF_IA32))
- value &= 0x;
switch (regno) {
case offsetof(struct user_regs_struct,fs):
if (value && (value & 3) != 3)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Linux 2.6.22.7
We (the -stable team) are announcing the release of the 2.6.22.7 kernel. It contains a single security bugfix for the x86_64 architecture. There is potential for local privilege escalation, so all x86_64 users are certainly encouraged to upgrade. CVE-2007-4573: x86_64: Zero extend all registers after ptrace in 32bit entry path. I'll also be replying to this message with a copy of the patch between 2.6.22.6 and 2.6.22.7 The updated 2.6.22.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.22.y.git and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.22.y.git;a=summary thanks, -chris Makefile |2 +- arch/x86_64/ia32/ia32entry.S | 18 +++--- arch/x86_64/kernel/ptrace.c |4 3 files changed, 16 insertions(+), 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 "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.6.22.7
We (the -stable team) are announcing the release of the 2.6.22.7 kernel. It contains a single security bugfix for the x86_64 architecture. There is potential for local privilege escalation, so all x86_64 users are certainly encouraged to upgrade. CVE-2007-4573: x86_64: Zero extend all registers after ptrace in 32bit entry path. I'll also be replying to this message with a copy of the patch between 2.6.22.6 and 2.6.22.7 The updated 2.6.22.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.22.y.git and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.22.y.git;a=summary thanks, -chris Makefile |2 +- arch/x86_64/ia32/ia32entry.S | 18 +++--- arch/x86_64/kernel/ptrace.c |4 3 files changed, 16 insertions(+), 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 unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.22.7
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 b/arch/x86_64/ia32/ia32entry.S
index 47565c3..0bc623a 100644
--- a/arch/x86_64/ia32/ia32entry.S
+++ b/arch/x86_64/ia32/ia32entry.S
@@ -38,6 +38,18 @@
movq%rax,R8(%rsp)
.endm
+ .macro LOAD_ARGS32 offset
+ movl \offset(%rsp),%r11d
+ movl \offset+8(%rsp),%r10d
+ movl \offset+16(%rsp),%r9d
+ movl \offset+24(%rsp),%r8d
+ movl \offset+40(%rsp),%ecx
+ movl \offset+48(%rsp),%edx
+ movl \offset+56(%rsp),%esi
+ movl \offset+64(%rsp),%edi
+ movl \offset+72(%rsp),%eax
+ .endm
+
.macro CFI_STARTPROC32 simple
CFI_STARTPROC \simple
CFI_UNDEFINED r8
@@ -152,7 +164,7 @@ sysenter_tracesys:
movq$-ENOSYS,RAX(%rsp) /* really needed? */
movq%rsp,%rdi/* pt_regs - arg1 */
callsyscall_trace_enter
- LOAD_ARGS ARGOFFSET /* reload args from stack in case ptrace changed
it */
+ LOAD_ARGS32 ARGOFFSET /* reload args from stack in case ptrace changed
it */
RESTORE_REST
movl%ebp, %ebp
/* no need to do an access_ok check here because rbp has been
@@ -255,7 +267,7 @@ cstar_tracesys:
movq $-ENOSYS,RAX(%rsp) /* really needed? */
movq %rsp,%rdi/* pt_regs - arg1 */
call syscall_trace_enter
- LOAD_ARGS ARGOFFSET /* reload args from stack in case ptrace changed
it */
+ LOAD_ARGS32 ARGOFFSET /* reload args from stack in case ptrace changed
it */
RESTORE_REST
movl RSP-ARGOFFSET(%rsp), %r8d
/* no need to do an access_ok check here because r8 has been
@@ -333,7 +345,7 @@ ia32_tracesys:
movq $-ENOSYS,RAX(%rsp) /* really needed? */
movq %rsp,%rdi/* pt_regs - arg1 */
call syscall_trace_enter
- LOAD_ARGS ARGOFFSET /* reload args from stack in case ptrace changed
it */
+ LOAD_ARGS32 ARGOFFSET /* reload args from stack in case ptrace changed
it */
RESTORE_REST
jmp ia32_do_syscall
END(ia32_syscall)
diff --git a/arch/x86_64/kernel/ptrace.c b/arch/x86_64/kernel/ptrace.c
index 9409117..8d89d8c 100644
--- a/arch/x86_64/kernel/ptrace.c
+++ b/arch/x86_64/kernel/ptrace.c
@@ -223,10 +223,6 @@ static int putreg(struct task_struct *child,
{
unsigned long tmp;
- /* Some code in the 64bit emulation may not be 64bit clean.
- Don't take any chances. */
- if (test_tsk_thread_flag(child, TIF_IA32))
- value = 0x;
switch (regno) {
case offsetof(struct user_regs_struct,fs):
if (value (value 3) != 3)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add I/O hypercalls for i386 paravirt
* 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 extentions. But that guest will be able to DMA anywhere in memory without VT-d, so if it's an untrusted guest you'd be taking a huge risk. thanks, -chris [1] Note: this is with the xenbits.xensource.com kernel, not with a kernel you'll get from kernel.org ATM. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add I/O hypercalls for i386 paravirt
* 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 Intel VT-d or AMD IOMMU) it's not DMA safe. thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Tech-board-discuss] Re: Linux Foundation Technical Advisory Board Elections
* 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 as you describe before the votes were cast (during the voting session). thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Tech-board-discuss] Re: Linux Foundation Technical Advisory Board Elections
* 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 as you describe before the votes were cast (during the voting session). thanks, -chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add I/O hypercalls for i386 paravirt
* 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 Intel VT-d or AMD IOMMU) it's not DMA safe. thanks, -chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add I/O hypercalls for i386 paravirt
* 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 extentions. But that guest will be able to DMA anywhere in memory without VT-d, so if it's an untrusted guest you'd be taking a huge risk. thanks, -chris [1] Note: this is with the xenbits.xensource.com kernel, not with a kernel you'll get from kernel.org ATM. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [5/12] x86_64: Make patching more robust, fix paravirt issue
* Rusty Russell ([EMAIL PROTECTED]) wrote:
> Then back out 19d36ccdc34f5ed444f8a6af0cbfdb6790eb1177 too, which broke
> lguest booting, and this tried to fix.
That did get backed out (at least the part that broke paravirt patching)
in 602033ed5907a59ce86f709082a35be047743a86. Linus' tree 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 PROTECTED]>
commit d34fda4a84c18402640a1a2342d6e6d9829e6db7 was a little overkill
in the case where a paravirt patcher chooses to leave patch site
unpatched. Instead of copying original instructions to temp buffer
then back to patch site, simply skip patching those sites altogether.
Cc: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: Zach Amsden <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
arch/i386/kernel/alternative.c |4 ++--
arch/i386/kernel/paravirt.c| 10 +-
arch/i386/kernel/vmi.c |4 ++--
include/asm-i386/paravirt.h|3 +++
4 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/arch/i386/kernel/alternative.c b/arch/i386/kernel/alternative.c
index 9f4ac8b..b81d87e 100644
--- a/arch/i386/kernel/alternative.c
+++ b/arch/i386/kernel/alternative.c
@@ -366,10 +366,10 @@ void apply_paravirt(struct paravirt_patch_site *start,
unsigned int used;
BUG_ON(p->len > MAX_PATCH_LEN);
- /* prep the buffer with the original instructions */
- memcpy(insnbuf, p->instr, p->len);
used = paravirt_ops.patch(p->instrtype, p->clobbers, insnbuf,
(unsigned long)p->instr, p->len);
+ if (used == PV_NO_PATCH)
+ continue;
BUG_ON(used > p->len);
diff --git a/arch/i386/kernel/paravirt.c b/arch/i386/kernel/paravirt.c
index 739cfb2..a36ce34 100644
--- a/arch/i386/kernel/paravirt.c
+++ b/arch/i386/kernel/paravirt.c
@@ -122,7 +122,7 @@ unsigned paravirt_patch_nop(void)
unsigned paravirt_patch_ignore(unsigned len)
{
- return len;
+ return PV_NO_PATCH;
}
struct branch {
@@ -139,9 +139,9 @@ unsigned paravirt_patch_call(void *insnbuf,
unsigned long delta = (unsigned long)target - (addr+5);
if (tgt_clobbers & ~site_clobbers)
- return len; /* target would clobber too much for this site
*/
+ return PV_NO_PATCH; /* target would clobber too much for
this site */
if (len < 5)
- return len; /* call too long for patch site */
+ return PV_NO_PATCH; /* call too long for patch site */
b->opcode = 0xe8; /* call */
b->delta = delta;
@@ -157,7 +157,7 @@ unsigned paravirt_patch_jmp(const void *target, void
*insnbuf,
unsigned long delta = (unsigned long)target - (addr+5);
if (len < 5)
- return len; /* call too long for patch site */
+ return PV_NO_PATCH; /* call too long for patch site */
b->opcode = 0xe9; /* jmp */
b->delta = delta;
@@ -196,7 +196,7 @@ unsigned paravirt_patch_insns(void *insnbuf, unsigned len,
unsigned insn_len = end - start;
if (insn_len > len || start == NULL)
- insn_len = len;
+ insn_len = PV_NO_PATCH;
else
memcpy(insnbuf, start, insn_len);
diff --git a/arch/i386/kernel/vmi.c b/arch/i386/kernel/vmi.c
index 18673e0..27ae004 100644
--- a/arch/i386/kernel/vmi.c
+++ b/arch/i386/kernel/vmi.c
@@ -118,7 +118,7 @@ static unsigned patch_internal(int call, unsigned len, void
*insnbuf,
case VMI_RELOCATION_NONE:
/* leave native code in place */
- break;
+ return PV_NO_PATCH;
default:
BUG();
@@ -153,7 +153,7 @@ static unsigned vmi_patch(u8 type, u16 clobbers, void
*insns,
default:
break;
}
- return len;
+ return PV_NO_PATCH;
}
/* CPUID has non-C semantics, and paravirt-ops API doesn't match hardware ISA
*/
diff --git a/include/asm-i386/paravirt.h b/include/asm-i386/paravirt.h
index 9fa3fa9..b26794f 100644
--- a/include/asm-i386/paravirt.h
+++ b/include/asm-i386/paravirt.h
@@ -252,6 +252,9 @@ extern struct paravirt_ops paravirt_ops;
#define paravirt_alt(insn_string) \
_paravirt_alt(insn_string, "%c[paravirt_typenum]",
"%c[paravirt_clobber]")
+enum {
+ PV_NO_PATCH = -1
+};
unsigned paravirt_patch_nop(void);
unsigned paravirt_patch_ignore(unsigned len);
Re: [PATCH] [5/12] x86_64: Make patching more robust, fix paravirt issue
* Rusty Russell ([EMAIL PROTECTED]) wrote:
Then back out 19d36ccdc34f5ed444f8a6af0cbfdb6790eb1177 too, which broke
lguest booting, and this tried to fix.
That did get backed out (at least the part that broke paravirt patching)
in 602033ed5907a59ce86f709082a35be047743a86. Linus' tree 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 PROTECTED]
commit d34fda4a84c18402640a1a2342d6e6d9829e6db7 was a little overkill
in the case where a paravirt patcher chooses to leave patch site
unpatched. Instead of copying original instructions to temp buffer
then back to patch site, simply skip patching those sites altogether.
Cc: Jeremy Fitzhardinge [EMAIL PROTECTED]
Cc: Rusty Russell [EMAIL PROTECTED]
Cc: Zach Amsden [EMAIL PROTECTED]
Signed-off-by: Chris Wright [EMAIL PROTECTED]
---
arch/i386/kernel/alternative.c |4 ++--
arch/i386/kernel/paravirt.c| 10 +-
arch/i386/kernel/vmi.c |4 ++--
include/asm-i386/paravirt.h|3 +++
4 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/arch/i386/kernel/alternative.c b/arch/i386/kernel/alternative.c
index 9f4ac8b..b81d87e 100644
--- a/arch/i386/kernel/alternative.c
+++ b/arch/i386/kernel/alternative.c
@@ -366,10 +366,10 @@ void apply_paravirt(struct paravirt_patch_site *start,
unsigned int used;
BUG_ON(p-len MAX_PATCH_LEN);
- /* prep the buffer with the original instructions */
- memcpy(insnbuf, p-instr, p-len);
used = paravirt_ops.patch(p-instrtype, p-clobbers, insnbuf,
(unsigned long)p-instr, p-len);
+ if (used == PV_NO_PATCH)
+ continue;
BUG_ON(used p-len);
diff --git a/arch/i386/kernel/paravirt.c b/arch/i386/kernel/paravirt.c
index 739cfb2..a36ce34 100644
--- a/arch/i386/kernel/paravirt.c
+++ b/arch/i386/kernel/paravirt.c
@@ -122,7 +122,7 @@ unsigned paravirt_patch_nop(void)
unsigned paravirt_patch_ignore(unsigned len)
{
- return len;
+ return PV_NO_PATCH;
}
struct branch {
@@ -139,9 +139,9 @@ unsigned paravirt_patch_call(void *insnbuf,
unsigned long delta = (unsigned long)target - (addr+5);
if (tgt_clobbers ~site_clobbers)
- return len; /* target would clobber too much for this site
*/
+ return PV_NO_PATCH; /* target would clobber too much for
this site */
if (len 5)
- return len; /* call too long for patch site */
+ return PV_NO_PATCH; /* call too long for patch site */
b-opcode = 0xe8; /* call */
b-delta = delta;
@@ -157,7 +157,7 @@ unsigned paravirt_patch_jmp(const void *target, void
*insnbuf,
unsigned long delta = (unsigned long)target - (addr+5);
if (len 5)
- return len; /* call too long for patch site */
+ return PV_NO_PATCH; /* call too long for patch site */
b-opcode = 0xe9; /* jmp */
b-delta = delta;
@@ -196,7 +196,7 @@ unsigned paravirt_patch_insns(void *insnbuf, unsigned len,
unsigned insn_len = end - start;
if (insn_len len || start == NULL)
- insn_len = len;
+ insn_len = PV_NO_PATCH;
else
memcpy(insnbuf, start, insn_len);
diff --git a/arch/i386/kernel/vmi.c b/arch/i386/kernel/vmi.c
index 18673e0..27ae004 100644
--- a/arch/i386/kernel/vmi.c
+++ b/arch/i386/kernel/vmi.c
@@ -118,7 +118,7 @@ static unsigned patch_internal(int call, unsigned len, void
*insnbuf,
case VMI_RELOCATION_NONE:
/* leave native code in place */
- break;
+ return PV_NO_PATCH;
default:
BUG();
@@ -153,7 +153,7 @@ static unsigned vmi_patch(u8 type, u16 clobbers, void
*insns,
default:
break;
}
- return len;
+ return PV_NO_PATCH;
}
/* CPUID has non-C semantics, and paravirt-ops API doesn't match hardware ISA
*/
diff --git a/include/asm-i386/paravirt.h b/include/asm-i386/paravirt.h
index 9fa3fa9..b26794f 100644
--- a/include/asm-i386/paravirt.h
+++ b/include/asm-i386/paravirt.h
@@ -252,6 +252,9 @@ extern struct paravirt_ops paravirt_ops;
#define paravirt_alt(insn_string) \
_paravirt_alt(insn_string, %c[paravirt_typenum],
%c[paravirt_clobber])
+enum {
+ PV_NO_PATCH = -1
+};
unsigned paravirt_patch_nop(void);
unsigned paravirt_patch_ignore(unsigned len);
unsigned paravirt_patch_call(void *insnbuf,
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
[PATCH] x86: skip paravirt patching when appropriate
* 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 still prefer a revert I've
> got one handy, and we can re-visit this all post .23.
This one avoids the patching when necessary, but needs some validation on
VMI (and Zach's not avail today). I'll resend when I know it's working
for all paravirt patchers.
thanks,
-chris
--
Subject: [PATCH] x86: skip paravirt patching when appropriate
From: Chris Wright <[EMAIL PROTECTED]>
commit d34fda4a84c18402640a1a2342d6e6d9829e6db7 was a little overkill
in the case where a paravirt patcher chooses to leave patch site
unpatched. Instead of copying original instructions to temp buffer
then back to patch site, simply skip patching those sites altogether.
Cc: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: Zach Amsden <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
arch/i386/kernel/alternative.c |4 ++--
arch/i386/kernel/paravirt.c| 10 +-
arch/i386/kernel/vmi.c |4 ++--
include/asm-i386/paravirt.h|3 +++
4 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/arch/i386/kernel/alternative.c b/arch/i386/kernel/alternative.c
index 9f4ac8b..b81d87e 100644
--- a/arch/i386/kernel/alternative.c
+++ b/arch/i386/kernel/alternative.c
@@ -366,10 +366,10 @@ void apply_paravirt(struct paravirt_patch_site *start,
unsigned int used;
BUG_ON(p->len > MAX_PATCH_LEN);
- /* prep the buffer with the original instructions */
- memcpy(insnbuf, p->instr, p->len);
used = paravirt_ops.patch(p->instrtype, p->clobbers, insnbuf,
(unsigned long)p->instr, p->len);
+ if (used == PV_NO_PATCH)
+ continue;
BUG_ON(used > p->len);
diff --git a/arch/i386/kernel/paravirt.c b/arch/i386/kernel/paravirt.c
index 739cfb2..a36ce34 100644
--- a/arch/i386/kernel/paravirt.c
+++ b/arch/i386/kernel/paravirt.c
@@ -122,7 +122,7 @@ unsigned paravirt_patch_nop(void)
unsigned paravirt_patch_ignore(unsigned len)
{
- return len;
+ return PV_NO_PATCH;
}
struct branch {
@@ -139,9 +139,9 @@ unsigned paravirt_patch_call(void *insnbuf,
unsigned long delta = (unsigned long)target - (addr+5);
if (tgt_clobbers & ~site_clobbers)
- return len; /* target would clobber too much for this site
*/
+ return PV_NO_PATCH; /* target would clobber too much for
this site */
if (len < 5)
- return len; /* call too long for patch site */
+ return PV_NO_PATCH; /* call too long for patch site */
b->opcode = 0xe8; /* call */
b->delta = delta;
@@ -157,7 +157,7 @@ unsigned paravirt_patch_jmp(const void *target, void
*insnbuf,
unsigned long delta = (unsigned long)target - (addr+5);
if (len < 5)
- return len; /* call too long for patch site */
+ return PV_NO_PATCH; /* call too long for patch site */
b->opcode = 0xe9; /* jmp */
b->delta = delta;
@@ -196,7 +196,7 @@ unsigned paravirt_patch_insns(void *insnbuf, unsigned len,
unsigned insn_len = end - start;
if (insn_len > len || start == NULL)
- insn_len = len;
+ insn_len = PV_NO_PATCH;
else
memcpy(insnbuf, start, insn_len);
diff --git a/arch/i386/kernel/vmi.c b/arch/i386/kernel/vmi.c
index 18673e0..27ae004 100644
--- a/arch/i386/kernel/vmi.c
+++ b/arch/i386/kernel/vmi.c
@@ -118,7 +118,7 @@ static unsigned patch_internal(int call, unsigned len, void
*insnbuf,
case VMI_RELOCATION_NONE:
/* leave native code in place */
- break;
+ return PV_NO_PATCH;
default:
BUG();
@@ -153,7 +153,7 @@ static unsigned vmi_patch(u8 type, u16 clobbers, void
*insns,
default:
break;
}
- return len;
+ return PV_NO_PATCH;
}
/* CPUID has non-C semantics, and paravirt-ops API doesn't match hardware ISA
*/
diff --git a/include/asm-i386/paravirt.h b/include/asm-i386/paravirt.h
index 9fa3fa9..b26794f 100644
--- a/include/asm-i386/paravirt.h
+++ b/include/asm-i386/paravirt.h
@@ -252,6 +252,9 @@ extern struct paravirt_ops paravirt_ops;
#define paravirt_alt(insn_string) \
_paravirt_alt(insn_string, "%c[paravirt_typenum]",
"%c[paravirt_clobber]")
+enum {
+ PV_NO_PATCH =
Re: [PATCH] [5/12] x86_64: Make patching more robust, fix paravirt issue
* 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 > > necessary. AFAICT patching is writing garbage into the insn stream. > > I suspect it's copying an uninitialized temp buffer. > > Can you send me the revert patch that is verified to work? 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 still prefer a revert I've got one handy, and we can re-visit this all post .23. thanks, -chris -- Subject: [PATCH] x86: properly initialize temp insn buffer for paravirt patching From: Chris Wright <[EMAIL PROTECTED]> With commit ab144f5ec64c42218a555ec1dbde6b60cf2982d6 the patching code now collects the complete new instruction stream into a temp buffer before finally patching in the new insns. In some cases the paravirt patchers will choose to leave the patch site unpatched (length mismatch, clobbers mismatch, etc). This causes the new patching code to copy an uninitialized temp buffer, i.e. garbage, to the callsite. Simply make sure to always initialize the buffer with the original instruction stream. A better fix is to audit all the patchers and return proper length so that apply_paravirt() can skip copies when we leave the patch site untouched. Signed-off-by: Chris Wright <[EMAIL PROTECTED]> --- arch/i386/kernel/alternative.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/i386/kernel/alternative.c b/arch/i386/kernel/alternative.c index 1b66d5c..9f4ac8b 100644 --- a/arch/i386/kernel/alternative.c +++ b/arch/i386/kernel/alternative.c @@ -366,6 +366,8 @@ void apply_paravirt(struct paravirt_patch_site *start, unsigned int used; BUG_ON(p->len > MAX_PATCH_LEN); + /* prep the buffer with the original instructions */ + memcpy(insnbuf, p->instr, p->len); used = paravirt_ops.patch(p->instrtype, p->clobbers, insnbuf, (unsigned long)p->instr, p->len); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [5/12] x86_64: Make patching more robust, fix paravirt issue
* 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 is writing garbage into the insn stream. I suspect it's copying an uninitialized temp buffer. thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [5/12] x86_64: Make patching more robust, fix paravirt issue
* 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 is writing garbage into the insn stream. I suspect it's copying an uninitialized temp buffer. thanks, -chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [5/12] x86_64: Make patching more robust, fix paravirt issue
* 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 necessary. AFAICT patching is writing garbage into the insn stream. I suspect it's copying an uninitialized temp buffer. Can you send me the revert patch that is verified to work? 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 still prefer a revert I've got one handy, and we can re-visit this all post .23. thanks, -chris -- Subject: [PATCH] x86: properly initialize temp insn buffer for paravirt patching From: Chris Wright [EMAIL PROTECTED] With commit ab144f5ec64c42218a555ec1dbde6b60cf2982d6 the patching code now collects the complete new instruction stream into a temp buffer before finally patching in the new insns. In some cases the paravirt patchers will choose to leave the patch site unpatched (length mismatch, clobbers mismatch, etc). This causes the new patching code to copy an uninitialized temp buffer, i.e. garbage, to the callsite. Simply make sure to always initialize the buffer with the original instruction stream. A better fix is to audit all the patchers and return proper length so that apply_paravirt() can skip copies when we leave the patch site untouched. Signed-off-by: Chris Wright [EMAIL PROTECTED] --- arch/i386/kernel/alternative.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/i386/kernel/alternative.c b/arch/i386/kernel/alternative.c index 1b66d5c..9f4ac8b 100644 --- a/arch/i386/kernel/alternative.c +++ b/arch/i386/kernel/alternative.c @@ -366,6 +366,8 @@ void apply_paravirt(struct paravirt_patch_site *start, unsigned int used; BUG_ON(p-len MAX_PATCH_LEN); + /* prep the buffer with the original instructions */ + memcpy(insnbuf, p-instr, p-len); used = paravirt_ops.patch(p-instrtype, p-clobbers, insnbuf, (unsigned long)p-instr, p-len); - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86: skip paravirt patching when appropriate
* 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 still prefer a revert I've
got one handy, and we can re-visit this all post .23.
This one avoids the patching when necessary, but needs some validation on
VMI (and Zach's not avail today). I'll resend when I know it's working
for all paravirt patchers.
thanks,
-chris
--
Subject: [PATCH] x86: skip paravirt patching when appropriate
From: Chris Wright [EMAIL PROTECTED]
commit d34fda4a84c18402640a1a2342d6e6d9829e6db7 was a little overkill
in the case where a paravirt patcher chooses to leave patch site
unpatched. Instead of copying original instructions to temp buffer
then back to patch site, simply skip patching those sites altogether.
Cc: Jeremy Fitzhardinge [EMAIL PROTECTED]
Cc: Rusty Russell [EMAIL PROTECTED]
Cc: Zach Amsden [EMAIL PROTECTED]
Signed-off-by: Chris Wright [EMAIL PROTECTED]
---
arch/i386/kernel/alternative.c |4 ++--
arch/i386/kernel/paravirt.c| 10 +-
arch/i386/kernel/vmi.c |4 ++--
include/asm-i386/paravirt.h|3 +++
4 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/arch/i386/kernel/alternative.c b/arch/i386/kernel/alternative.c
index 9f4ac8b..b81d87e 100644
--- a/arch/i386/kernel/alternative.c
+++ b/arch/i386/kernel/alternative.c
@@ -366,10 +366,10 @@ void apply_paravirt(struct paravirt_patch_site *start,
unsigned int used;
BUG_ON(p-len MAX_PATCH_LEN);
- /* prep the buffer with the original instructions */
- memcpy(insnbuf, p-instr, p-len);
used = paravirt_ops.patch(p-instrtype, p-clobbers, insnbuf,
(unsigned long)p-instr, p-len);
+ if (used == PV_NO_PATCH)
+ continue;
BUG_ON(used p-len);
diff --git a/arch/i386/kernel/paravirt.c b/arch/i386/kernel/paravirt.c
index 739cfb2..a36ce34 100644
--- a/arch/i386/kernel/paravirt.c
+++ b/arch/i386/kernel/paravirt.c
@@ -122,7 +122,7 @@ unsigned paravirt_patch_nop(void)
unsigned paravirt_patch_ignore(unsigned len)
{
- return len;
+ return PV_NO_PATCH;
}
struct branch {
@@ -139,9 +139,9 @@ unsigned paravirt_patch_call(void *insnbuf,
unsigned long delta = (unsigned long)target - (addr+5);
if (tgt_clobbers ~site_clobbers)
- return len; /* target would clobber too much for this site
*/
+ return PV_NO_PATCH; /* target would clobber too much for
this site */
if (len 5)
- return len; /* call too long for patch site */
+ return PV_NO_PATCH; /* call too long for patch site */
b-opcode = 0xe8; /* call */
b-delta = delta;
@@ -157,7 +157,7 @@ unsigned paravirt_patch_jmp(const void *target, void
*insnbuf,
unsigned long delta = (unsigned long)target - (addr+5);
if (len 5)
- return len; /* call too long for patch site */
+ return PV_NO_PATCH; /* call too long for patch site */
b-opcode = 0xe9; /* jmp */
b-delta = delta;
@@ -196,7 +196,7 @@ unsigned paravirt_patch_insns(void *insnbuf, unsigned len,
unsigned insn_len = end - start;
if (insn_len len || start == NULL)
- insn_len = len;
+ insn_len = PV_NO_PATCH;
else
memcpy(insnbuf, start, insn_len);
diff --git a/arch/i386/kernel/vmi.c b/arch/i386/kernel/vmi.c
index 18673e0..27ae004 100644
--- a/arch/i386/kernel/vmi.c
+++ b/arch/i386/kernel/vmi.c
@@ -118,7 +118,7 @@ static unsigned patch_internal(int call, unsigned len, void
*insnbuf,
case VMI_RELOCATION_NONE:
/* leave native code in place */
- break;
+ return PV_NO_PATCH;
default:
BUG();
@@ -153,7 +153,7 @@ static unsigned vmi_patch(u8 type, u16 clobbers, void
*insns,
default:
break;
}
- return len;
+ return PV_NO_PATCH;
}
/* CPUID has non-C semantics, and paravirt-ops API doesn't match hardware ISA
*/
diff --git a/include/asm-i386/paravirt.h b/include/asm-i386/paravirt.h
index 9fa3fa9..b26794f 100644
--- a/include/asm-i386/paravirt.h
+++ b/include/asm-i386/paravirt.h
@@ -252,6 +252,9 @@ extern struct paravirt_ops paravirt_ops;
#define paravirt_alt(insn_string) \
_paravirt_alt(insn_string, %c[paravirt_typenum],
%c[paravirt_clobber])
+enum {
+ PV_NO_PATCH = -1
+};
unsigned paravirt_patch_nop(void);
unsigned paravirt_patch_ignore(unsigned len);
unsigned paravirt_patch_call(void *insnbuf,
-
To unsubscribe from
Re: [PATCH] [5/12] x86_64: Make patching more robust, fix paravirt issue
* 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 failure mode; its a > little hard to debug because it overwrites all kernel memory with > recursive fault stackframes and then finally traps out to Xen when it > hits the bottom of memory. > > I think we should back this one out before .23. I agree (second time this has broken during .23 devel). thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [5/12] x86_64: Make patching more robust, fix paravirt issue
* 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 failure mode; its a little hard to debug because it overwrites all kernel memory with recursive fault stackframes and then finally traps out to Xen when it hits the bottom of memory. I think we should back this one out before .23. I agree (second time this has broken during .23 devel). thanks, -chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] [PATCH] UML - Add a .note.SuSE section
* 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 unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] [PATCH] UML - Add a .note.SuSE section
* 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 unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH take2] Use ERESTART_RESTARTBLOCK if poll() is interrupted by a signal
* 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->arg3<<32) | (s64)restart_block->arg2;
> > + int ret;
> > +
> > + restart_block->fn = do_no_restart_syscall;
>
> (just in case, this is not strictly necessary)
Removed, thanks.
> > + ret = do_sys_poll(ufds, nfds, );
> > + if (ret == -EINTR) {
> > + restart_block->fn = do_restart_poll;
> > + restart_block->arg2 = timeout & 0x;
> > + restart_block->arg3 = timeout >> 32;
> > + ret = -ERESTART_RESTARTBLOCK;
> > + }
> > + return ret;
> > +}
> > +
> > asmlinkage long sys_poll(struct pollfd __user *ufds, unsigned int nfds,
> > long timeout_msecs)
> > {
> > s64 timeout_jiffies;
> > + int ret;
> >
> > if (timeout_msecs > 0) {
> > #if HZ > 1000
> > @@ -754,7 +773,20 @@ asmlinkage long sys_poll(struct pollfd __user *ufds,
> > unsigned int nfds,
> > timeout_jiffies = timeout_msecs;
> > }
> >
> > - return do_sys_poll(ufds, nfds, _jiffies);
> > + ret = do_sys_poll(ufds, nfds, _jiffies);
> > + if (ret == -EINTR) {
> > + if (timeout_msecs > 0) {
>
> This should be "if (timeout_msecs)", a negative timeout means
> "wait indefinitely", so we should restart as well.
Yes, you're right (not really sure what I was thinking there ;-)
> > + struct restart_block *restart_block;
> > + restart_block = _thread_info()->restart_block;
> > + restart_block->fn = do_restart_poll;
> > + restart_block->arg0 = (unsigned long)ufds;
> > + restart_block->arg1 = nfds;
> > + restart_block->arg2 = timeout_jiffies & 0x;
> > + restart_block->arg3 = timeout_jiffies >> 32;
>
> and, in that case, we should use "(u64)timeout_jiffies >> 32".
Sure, sign extension should get shifted back off, but that is more
accurate.
> Small nit: sys_poll() and do_restart_poll() are not "symmetrical", the latter
> doesn't check *timeout at all. Either way is correct, restart with zero
> timeout
> means "try again once but doesn't wait".
>
> There is a subtle (but harmless) difference though. Suppose that *timeout == 0
> (either because timeout_msecs == 0 or because timeout expiried) and we have a
> "false" signal_pending(). In that case sys_poll() returns EINTR, but
> do_restart_poll()
> returns 0.
>
> I was a bit surprized that sys_poll() return EINTR even if timeout expired,
> but
> preserved this behaviour in do_poll-return-eintr-when-signalled.patch.
>
> Perhaps it is better to just remove "if (timeout_msecs > 0)" check from
> sys_poll().
> Then we can modify do_poll() to return EINTR only when !*timeout, to eliminate
> unneeded (but correct) restart.
>
> What do you think?
I agree. Here's the respin.
thanks,
-chris
--
Subject: [PATCH take2] 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 is an ignored signal. In general
poll is a little eager in returning EINTR, when it could try not bother
userspace and simply restart the syscall. Both select and ppoll do use
ERESTARTNOHAND to restart the syscall. Oleg points out that simply using
ERESTARTNOHAND will cause poll to restart with original timeout value.
which could ultimately lead to process never returning to userspace.
Instead use ERESTART_RESTARTBLOCK, and restart poll with updated timeout
value. Inspired by Manfred's use ERESTARTNOHAND in poll patch.
Cc: Manfred Spraul <[EMAIL PROTECTED]>
Cc: Oleg Nesterov <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>
Cc: Roland McGrath <[EMAIL PROTECTED]>
Cc: "Agarwal, Lomesh" <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
Patch against git-28e8351a
fs/select.c | 31 ++-
1 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/fs/select.c b/fs/select.c
index a974082..5562195 100644
--- a/fs/select.c
+++ b/fs/select.c
@@ -736,10 +736,28 @@ out
Re: [PATCH 3/25][V3] irq_flags / halt routines
* 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 paravirt_arch_setup, which is currently unused, with code to > replace the needed paravirt_ops.fn. > > I don't know if there is any method to dynamically determine (at this > point) that we are in a vsmp arch, and if there are not, it will have to > get ifdefs anyway. But at least, they are far more local. between __cacheline_aligned_in_smp and other compile time bits based on VSMP specific INTERNODE_CACHE, etc. I think compile time the way to go. > I am okay with both, but after all the explanation, I don't think that > adding a new pvops is a bad idea. It would make things less cumbersome > in this case. Also, hacks like this save_fl may require changes to the > hypervisor, right? I don't even know where such hypervisor is, and how > easy it is to replace it (it may be deeply hidden in firmware) No hypervisor change needed. Just the pv backend needs to return 0 or X86_EFLAGS_IF for save_flags (and similar translation on restore_flags). Xen uses a simple shared memory flag and does something which you could roughly translate into this: xen_save_flags() if (xen_vcpu_interrupts_enabled) return X86_EFLAGS_IF; else return 0; This doesn't require any hypervisor changes. Similarly, VSMP could do something along the lines of: vsmp_save_flags() flags = native_save_flags(); if (flags & X86_EFLAGS_IF) || (flags & X86_EFLAGS_AC) return X86_EFLAGS_IF; else return 0; > A question raises here: Would vsmp turn paravirt_enabled to 1 ? Probably not. It's mostly native and I'm not sure it would want the bits disabled from if (paravirt_enabled()) tests. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/25][V3] irq_flags / halt routines
* 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 somewhere like vsmp.c, or similar (or maybe > even assigning paravirt_ops.fn = vsmp_fn on the fly, but early enough). This is the best (just override pvops.fn for the few needed for VSMP). The irq_disabled_flags() is the only problem. For i386 we dropped it (disabled_flags) as a pvop and forced the backend to provide a flags (via save_flags) that conforms to IF only. thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/25][V3] irq_flags / halt routines
* 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 somewhere like vsmp.c, or similar (or maybe even assigning paravirt_ops.fn = vsmp_fn on the fly, but early enough). This is the best (just override pvops.fn for the few needed for VSMP). The irq_disabled_flags() is the only problem. For i386 we dropped it (disabled_flags) as a pvop and forced the backend to provide a flags (via save_flags) that conforms to IF only. thanks, -chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/25][V3] irq_flags / halt routines
* 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 paravirt_arch_setup, which is currently unused, with code to replace the needed paravirt_ops.fn. I don't know if there is any method to dynamically determine (at this point) that we are in a vsmp arch, and if there are not, it will have to get ifdefs anyway. But at least, they are far more local. between __cacheline_aligned_in_smp and other compile time bits based on VSMP specific INTERNODE_CACHE, etc. I think compile time the way to go. I am okay with both, but after all the explanation, I don't think that adding a new pvops is a bad idea. It would make things less cumbersome in this case. Also, hacks like this save_fl may require changes to the hypervisor, right? I don't even know where such hypervisor is, and how easy it is to replace it (it may be deeply hidden in firmware) No hypervisor change needed. Just the pv backend needs to return 0 or X86_EFLAGS_IF for save_flags (and similar translation on restore_flags). Xen uses a simple shared memory flag and does something which you could roughly translate into this: xen_save_flags() if (xen_vcpu_interrupts_enabled) return X86_EFLAGS_IF; else return 0; This doesn't require any hypervisor changes. Similarly, VSMP could do something along the lines of: vsmp_save_flags() flags = native_save_flags(); if (flags X86_EFLAGS_IF) || (flags X86_EFLAGS_AC) return X86_EFLAGS_IF; else return 0; A question raises here: Would vsmp turn paravirt_enabled to 1 ? Probably not. It's mostly native and I'm not sure it would want the bits disabled from if (paravirt_enabled()) tests. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH take2] Use ERESTART_RESTARTBLOCK if poll() is interrupted by a signal
* 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-arg332) | (s64)restart_block-arg2;
+ int ret;
+
+ restart_block-fn = do_no_restart_syscall;
(just in case, this is not strictly necessary)
Removed, thanks.
+ ret = do_sys_poll(ufds, nfds, timeout);
+ if (ret == -EINTR) {
+ restart_block-fn = do_restart_poll;
+ restart_block-arg2 = timeout 0x;
+ restart_block-arg3 = timeout 32;
+ ret = -ERESTART_RESTARTBLOCK;
+ }
+ return ret;
+}
+
asmlinkage long sys_poll(struct pollfd __user *ufds, unsigned int nfds,
long timeout_msecs)
{
s64 timeout_jiffies;
+ int ret;
if (timeout_msecs 0) {
#if HZ 1000
@@ -754,7 +773,20 @@ asmlinkage long sys_poll(struct pollfd __user *ufds,
unsigned int nfds,
timeout_jiffies = timeout_msecs;
}
- return do_sys_poll(ufds, nfds, timeout_jiffies);
+ ret = do_sys_poll(ufds, nfds, timeout_jiffies);
+ if (ret == -EINTR) {
+ if (timeout_msecs 0) {
This should be if (timeout_msecs), a negative timeout means
wait indefinitely, so we should restart as well.
Yes, you're right (not really sure what I was thinking there ;-)
+ struct restart_block *restart_block;
+ restart_block = current_thread_info()-restart_block;
+ restart_block-fn = do_restart_poll;
+ restart_block-arg0 = (unsigned long)ufds;
+ restart_block-arg1 = nfds;
+ restart_block-arg2 = timeout_jiffies 0x;
+ restart_block-arg3 = timeout_jiffies 32;
and, in that case, we should use (u64)timeout_jiffies 32.
Sure, sign extension should get shifted back off, but that is more
accurate.
Small nit: sys_poll() and do_restart_poll() are not symmetrical, the latter
doesn't check *timeout at all. Either way is correct, restart with zero
timeout
means try again once but doesn't wait.
There is a subtle (but harmless) difference though. Suppose that *timeout == 0
(either because timeout_msecs == 0 or because timeout expiried) and we have a
false signal_pending(). In that case sys_poll() returns EINTR, but
do_restart_poll()
returns 0.
I was a bit surprized that sys_poll() return EINTR even if timeout expired,
but
preserved this behaviour in do_poll-return-eintr-when-signalled.patch.
Perhaps it is better to just remove if (timeout_msecs 0) check from
sys_poll().
Then we can modify do_poll() to return EINTR only when !*timeout, to eliminate
unneeded (but correct) restart.
What do you think?
I agree. Here's the respin.
thanks,
-chris
--
Subject: [PATCH take2] 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 is an ignored signal. In general
poll is a little eager in returning EINTR, when it could try not bother
userspace and simply restart the syscall. Both select and ppoll do use
ERESTARTNOHAND to restart the syscall. Oleg points out that simply using
ERESTARTNOHAND will cause poll to restart with original timeout value.
which could ultimately lead to process never returning to userspace.
Instead use ERESTART_RESTARTBLOCK, and restart poll with updated timeout
value. Inspired by Manfred's use ERESTARTNOHAND in poll patch.
Cc: Manfred Spraul [EMAIL PROTECTED]
Cc: Oleg Nesterov [EMAIL PROTECTED]
Cc: Andrew Morton [EMAIL PROTECTED]
Cc: Roland McGrath [EMAIL PROTECTED]
Cc: Agarwal, Lomesh [EMAIL PROTECTED]
Signed-off-by: Chris Wright [EMAIL PROTECTED]
---
Patch against git-28e8351a
fs/select.c | 31 ++-
1 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/fs/select.c b/fs/select.c
index a974082..5562195 100644
--- a/fs/select.c
+++ b/fs/select.c
@@ -736,10 +736,28 @@ out_fds:
return err;
}
+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-arg332) | (s64)restart_block-arg2;
+ int ret;
+
+ ret = do_sys_poll(ufds, nfds, timeout);
+ if (ret == -EINTR) {
+ restart_block-fn = do_restart_poll;
+ restart_block-arg2 = timeout 0x;
+ restart_block-arg3 = (u64)timeout 32;
+ ret = -ERESTART_RESTARTBLOCK;
+ }
+ return ret;
+}
+
asmlinkage long sys_poll(struct pollfd __user *ufds, unsigned int nfds
Re: [PATCH] [545/2many] MAINTAINERS - XEN HYPERVISOR INTERFACE
* 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/ > > > > I think this data will easily become stale. What is the point again? > > Agreed. But not everyone wants to or should have to use git, > so what are the alternatives? Between git (or gitweb), existing MAINTAINERS and a bit of common sense (or extra sleuthing), I never perceived a significant problem. Alternative could be to place info directly in source files. If not all of MAINTAINERS info, it could be a tag to reference the relevant MAINTAINERS entry. thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [545/2many] MAINTAINERS - XEN HYPERVISOR INTERFACE
* [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: [EMAIL PROTECTED] > L: [EMAIL PROTECTED] > S: Supported > +F: arch/i386/xen/ > +F: drivers/*/xen-*front.c > +F: drivers/xen/ > +F: include/asm-i386/xen/ > +F: include/xen/ I think this data will easily become stale. What is the point again? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [365/2many] MAINTAINERS - PARAVIRT_OPS INTERFACE
* [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] > L: linux-kernel@vger.kernel.org > S: Supported > +F: arch/i386/kernel/paravirt.c > +F: include/asm-i386/paravirt.h > +F: include/asm-um/paravirt.h Not asm-um. And it's much more spread out than that, touching many non-paravirt specific files (as in include/asm-i386/ and search for CONFIG_PARAVIRT). I'm failing to see the value of this churn. thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [365/2many] MAINTAINERS - PARAVIRT_OPS INTERFACE
* [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] L: linux-kernel@vger.kernel.org S: Supported +F: arch/i386/kernel/paravirt.c +F: include/asm-i386/paravirt.h +F: include/asm-um/paravirt.h Not asm-um. And it's much more spread out than that, touching many non-paravirt specific files (as in include/asm-i386/ and search for CONFIG_PARAVIRT). I'm failing to see the value of this churn. thanks, -chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [545/2many] MAINTAINERS - XEN HYPERVISOR INTERFACE
* [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: [EMAIL PROTECTED] L: [EMAIL PROTECTED] S: Supported +F: arch/i386/xen/ +F: drivers/*/xen-*front.c +F: drivers/xen/ +F: include/asm-i386/xen/ +F: include/xen/ I think this data will easily become stale. What is the point again? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [545/2many] MAINTAINERS - XEN HYPERVISOR INTERFACE
* 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/ I think this data will easily become stale. What is the point again? Agreed. But not everyone wants to or should have to use git, so what are the alternatives? Between git (or gitweb), existing MAINTAINERS and a bit of common sense (or extra sleuthing), I never perceived a significant problem. Alternative could be to place info directly in source files. If not all of MAINTAINERS info, it could be a tag to reference the relevant MAINTAINERS entry. thanks, -chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Use ERESTART_RESTARTBLOCK if poll() is interrupted by a signal (was: Re: [PATCH] Use ERESTARTNOHAND if poll() is interrupted by a signal)
* Oleg Nesterov ([EMAIL PROTECTED]) wrote:
> What we need is ERESTART_RESTARTBLOCK, and restart_block.arg2 should
> have the new timeout value, which takes the time we already slept
> into account.
This passes my simple 32-bit and 64-bit testing. See any issues with
this one?
thanks,
-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 what in effect is an ignored signal. In general
poll is a little eager in returning EINTR, when it could try not bother
userspace and simply restart the syscall. Both select and ppoll do use
ERESTARTNOHAND to restart the syscall. Oleg points out that simply using
ERESTARTNOHAND will cause poll to restart with original timeout value.
which could ultimately lead to process never returning to userspace.
Instead use ERESTART_RESTARTBLOCK, and restart poll with updated timeout
value. Inspired by Manfred's use ERESTARTNOHAND in poll patch.
Cc: Manfred Spraul <[EMAIL PROTECTED]>
Cc: Oleg Nesterov <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>
Cc: Roland McGrath <[EMAIL PROTECTED]>
Cc: "Agarwal, Lomesh" <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
Patch against git-7a883eaf
fs/select.c | 34 +-
1 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/fs/select.c b/fs/select.c
index a974082..50e6d8e 100644
--- a/fs/select.c
+++ b/fs/select.c
@@ -736,10 +736,29 @@ out_fds:
return err;
}
+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->arg3<<32) | (s64)restart_block->arg2;
+ int ret;
+
+ restart_block->fn = do_no_restart_syscall;
+ ret = do_sys_poll(ufds, nfds, );
+ if (ret == -EINTR) {
+ restart_block->fn = do_restart_poll;
+ restart_block->arg2 = timeout & 0x;
+ restart_block->arg3 = timeout >> 32;
+ ret = -ERESTART_RESTARTBLOCK;
+ }
+ return ret;
+}
+
asmlinkage long sys_poll(struct pollfd __user *ufds, unsigned int nfds,
long timeout_msecs)
{
s64 timeout_jiffies;
+ int ret;
if (timeout_msecs > 0) {
#if HZ > 1000
@@ -754,7 +773,20 @@ asmlinkage long sys_poll(struct pollfd __user *ufds,
unsigned int nfds,
timeout_jiffies = timeout_msecs;
}
- return do_sys_poll(ufds, nfds, _jiffies);
+ ret = do_sys_poll(ufds, nfds, _jiffies);
+ if (ret == -EINTR) {
+ if (timeout_msecs > 0) {
+ struct restart_block *restart_block;
+ restart_block = _thread_info()->restart_block;
+ restart_block->fn = do_restart_poll;
+ restart_block->arg0 = (unsigned long)ufds;
+ restart_block->arg1 = nfds;
+ restart_block->arg2 = timeout_jiffies & 0x;
+ restart_block->arg3 = timeout_jiffies >> 32;
+ ret = -ERESTART_RESTARTBLOCK;
+ }
+ }
+ return ret;
}
#ifdef TIF_RESTORE_SIGMASK
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Use ERESTART_RESTARTBLOCK if poll() is interrupted by a signal (was: Re: [PATCH] Use ERESTARTNOHAND if poll() is interrupted by a signal)
* Oleg Nesterov ([EMAIL PROTECTED]) wrote:
What we need is ERESTART_RESTARTBLOCK, and restart_block.arg2 should
have the new timeout value, which takes the time we already slept
into account.
This passes my simple 32-bit and 64-bit testing. See any issues with
this one?
thanks,
-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 what in effect is an ignored signal. In general
poll is a little eager in returning EINTR, when it could try not bother
userspace and simply restart the syscall. Both select and ppoll do use
ERESTARTNOHAND to restart the syscall. Oleg points out that simply using
ERESTARTNOHAND will cause poll to restart with original timeout value.
which could ultimately lead to process never returning to userspace.
Instead use ERESTART_RESTARTBLOCK, and restart poll with updated timeout
value. Inspired by Manfred's use ERESTARTNOHAND in poll patch.
Cc: Manfred Spraul [EMAIL PROTECTED]
Cc: Oleg Nesterov [EMAIL PROTECTED]
Cc: Andrew Morton [EMAIL PROTECTED]
Cc: Roland McGrath [EMAIL PROTECTED]
Cc: Agarwal, Lomesh [EMAIL PROTECTED]
Signed-off-by: Chris Wright [EMAIL PROTECTED]
---
Patch against git-7a883eaf
fs/select.c | 34 +-
1 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/fs/select.c b/fs/select.c
index a974082..50e6d8e 100644
--- a/fs/select.c
+++ b/fs/select.c
@@ -736,10 +736,29 @@ out_fds:
return err;
}
+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-arg332) | (s64)restart_block-arg2;
+ int ret;
+
+ restart_block-fn = do_no_restart_syscall;
+ ret = do_sys_poll(ufds, nfds, timeout);
+ if (ret == -EINTR) {
+ restart_block-fn = do_restart_poll;
+ restart_block-arg2 = timeout 0x;
+ restart_block-arg3 = timeout 32;
+ ret = -ERESTART_RESTARTBLOCK;
+ }
+ return ret;
+}
+
asmlinkage long sys_poll(struct pollfd __user *ufds, unsigned int nfds,
long timeout_msecs)
{
s64 timeout_jiffies;
+ int ret;
if (timeout_msecs 0) {
#if HZ 1000
@@ -754,7 +773,20 @@ asmlinkage long sys_poll(struct pollfd __user *ufds,
unsigned int nfds,
timeout_jiffies = timeout_msecs;
}
- return do_sys_poll(ufds, nfds, timeout_jiffies);
+ ret = do_sys_poll(ufds, nfds, timeout_jiffies);
+ if (ret == -EINTR) {
+ if (timeout_msecs 0) {
+ struct restart_block *restart_block;
+ restart_block = current_thread_info()-restart_block;
+ restart_block-fn = do_restart_poll;
+ restart_block-arg0 = (unsigned long)ufds;
+ restart_block-arg1 = nfds;
+ restart_block-arg2 = timeout_jiffies 0x;
+ restart_block-arg3 = timeout_jiffies 32;
+ ret = -ERESTART_RESTARTBLOCK;
+ }
+ }
+ return ret;
}
#ifdef TIF_RESTORE_SIGMASK
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Use ERESTARTNOHAND if poll() is interrupted by a signal
* 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 *tvp" before return, but sys_poll() > gets timeout_msecs by value. Yeah, you're right. Means sys_poll with STOP/CONT cycles going in background (and no fds ready) would never return. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Use ERESTARTNOHAND if poll() is interrupted by a signal
* 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 *tvp before return, but sys_poll() gets timeout_msecs by value. Yeah, you're right. Means sys_poll with STOP/CONT cycles going in background (and no fds ready) would never return. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23-rc1 REGRESSION] CPU hotplug totally broken on HPC nx6325 (x86_64)
* 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 patching. > That said, I do wonder whether virtualization still has problems with > CONFIG_RODATA, though. We limit the RODATA memory ranges based on KPROBES > and HOTPLUG_CPU, but not based on VIRTUALIZATION. > > I'd expect any virtualization fixups to hit the same problems that the SMP > alternatives hit. No? Hmm, patching should've already happened, and aside of module loading, isn't typically done again. I think it's OK as it is. thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23-rc1 REGRESSION] CPU hotplug totally broken on HPC nx6325 (x86_64)
* 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 > > continuously on the console, no reaction to anything except for the power > > button). For this reason, suspend and hibernation don't work as well. > > Yeah, I really shouldn't have applied that patch. I didn't notice that it > not only cleaned up the direct memcpy's, it also re-introduced the damn > broken code that we fixed once already. This also fixes paravirt patching which was broken when text_poke() tried to patch the various pv ops in lookup_address. thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Use ERESTARTNOHAND if poll() is interrupted by a signal
* 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. > > select() and ppoll() both use ERESTARTNOHAND, this avoids a return to > > user space for signals that are handled by the kernel. > > > > The patch switches poll() to ERESTARTNOHAND. > > Tested with FC6. Patch against 2.6.23-rc1-mm1. > > hm. Is this a fix against > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc1/2.6.23-rc1-mm1/broken-out/do_poll-return-eintr-when-signalled.patch > only, or does mainline also need fixing? Mainline has same issue (although fix is certainly a bit different w/out Oleg's patch). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Use ERESTARTNOHAND if poll() is interrupted by a signal
* 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 space for signals that are handled by the kernel. This does change user visible behaviour, however, it's already inconsistent as you've noted. I was concerned about that change, but wrote some tests and this behaviour does make sense to me. thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Use ERESTARTNOHAND if poll() is interrupted by a signal
* 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 space for signals that are handled by the kernel. This does change user visible behaviour, however, it's already inconsistent as you've noted. I was concerned about that change, but wrote some tests and this behaviour does make sense to me. thanks, -chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Use ERESTARTNOHAND if poll() is interrupted by a signal
* 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. select() and ppoll() both use ERESTARTNOHAND, this avoids a return to user space for signals that are handled by the kernel. The patch switches poll() to ERESTARTNOHAND. Tested with FC6. Patch against 2.6.23-rc1-mm1. hm. Is this a fix against ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc1/2.6.23-rc1-mm1/broken-out/do_poll-return-eintr-when-signalled.patch only, or does mainline also need fixing? Mainline has same issue (although fix is certainly a bit different w/out Oleg's patch). - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23-rc1 REGRESSION] CPU hotplug totally broken on HPC nx6325 (x86_64)
* 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 continuously on the console, no reaction to anything except for the power button). For this reason, suspend and hibernation don't work as well. Yeah, I really shouldn't have applied that patch. I didn't notice that it not only cleaned up the direct memcpy's, it also re-introduced the damn broken code that we fixed once already. This also fixes paravirt patching which was broken when text_poke() tried to patch the various pv ops in lookup_address. thanks, -chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23-rc1 REGRESSION] CPU hotplug totally broken on HPC nx6325 (x86_64)
* 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 patching. That said, I do wonder whether virtualization still has problems with CONFIG_RODATA, though. We limit the RODATA memory ranges based on KPROBES and HOTPLUG_CPU, but not based on VIRTUALIZATION. I'd expect any virtualization fixups to hit the same problems that the SMP alternatives hit. No? Hmm, patching should've already happened, and aside of module loading, isn't typically done again. I think it's OK as it is. thanks, -chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, Announce] Unified x86 architecture, arch/x86
* 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. Funny, I was just looking at that code specifically. Yes, it would be useful to share. It will need some wrappers for the asm which are now paravirt on i386 and still raw on x86_64 (have those handy if you need them). thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, Announce] Unified x86 architecture, arch/x86
* 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. Funny, I was just looking at that code specifically. Yes, it would be useful to share. It will need some wrappers for the asm which are now paravirt on i386 and still raw on x86_64 (have those handy if you need them). thanks, -chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, Announce] Unified x86 architecture, arch/x86
* 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 +-
Makefile | 23 +-
arch/i386/Kconfig | 1275 +-
arch/i386/Makefile | 208 +--
arch/i386/kernel/early_printk.c|2 -
arch/i386/kernel/tsc_sync.c|1 -
arch/x86/Kconfig | 1919
arch/{i386 => x86}/Kconfig.cpu |0
arch/{i386 => x86}/Kconfig.debug | 50 +-
arch/x86/Kconfig_32| 1283 +
arch/{i386/Kconfig.debug => x86/Kconfig_32.debug} |0
arch/x86/Kconfig_64| 792
.../{x86_64/Kconfig.debug => x86/Kconfig_64.debug} |0
arch/x86/Makefile |5 +
arch/{i386 => x86}/Makefile.cpu|0
arch/x86/Makefile_32 | 163 ++
arch/x86/Makefile_64 | 128 ++
arch/{i386 => x86}/boot/.gitignore |0
arch/{i386 => x86}/boot/Makefile |6 +-
arch/{i386 => x86}/boot/a20.c |0
arch/{i386 => x86}/boot/apm.c |0
arch/{i386 => x86}/boot/bitops.h |0
arch/{i386 => x86}/boot/boot.h |0
arch/{i386 => x86}/boot/cmdline.c |0
arch/{i386 => x86}/boot/code16gcc.h|0
arch/{i386 => x86}/boot/compressed/.gitignore |0
arch/x86/boot/compressed/Makefile |5 +
.../Makefile => x86/boot/compressed/Makefile_32} |8 +-
.../Makefile => x86/boot/compressed/Makefile_64} |8 +-
.../head.S => x86/boot/compressed/head_32.S} |0
.../head.S => x86/boot/compressed/head_64.S} |0
.../misc.c => x86/boot/compressed/misc_32.c} |0
.../misc.c => x86/boot/compressed/misc_64.c} |0
arch/{i386 => x86}/boot/compressed/relocs.c|0
.../boot/compressed/vmlinux_32.lds}|0
.../boot/compressed/vmlinux_32.scr}|0
.../boot/compressed/vmlinux_64.lds}|0
.../boot/compressed/vmlinux_64.scr}|0
arch/{i386 => x86}/boot/copy.S |0
arch/{i386 => x86}/boot/cpu.c |0
arch/{i386 => x86}/boot/cpucheck.c |0
arch/{i386 => x86}/boot/edd.c |0
arch/{i386 => x86}/boot/header.S |0
arch/{i386 => x86}/boot/install.sh |0
arch/{i386 => x86}/boot/main.c |0
arch/{i386 => x86}/boot/mca.c |0
arch/{i386 => x86}/boot/memory.c |0
arch/{i386 => x86}/boot/mtools.conf.in |0
arch/{i386 => x86}/boot/pm.c |0
arch/{i386 => x86}/boot/pmjump.S |0
arch/{i386 => x86}/boot/printf.c |0
arch/x86/boot/setup.S |7 +
arch/{i386 => x86}/boot/setup.ld |0
arch/{i386 => x86}/boot/string.c |0
arch/{i386 => x86}/boot/tools/.gitignore |0
arch/{i386 => x86}/boot/tools/build.c |0
arch/{i386 => x86}/boot/tty.c |0
arch/{i386 => x86}/boot/version.c |0
arch/{i386 => x86}/boot/vesa.h |0
arch/{i386 => x86}/boot/video-bios.c |0
arch/{i386 => x86}/boot/video-vesa.c |0
arch/{i386 => x86}/boot/video-vga.c|0
arch/{i386 => x86}/boot/video.c|0
arch/{i386 => x86}/boot/video.h|0
arch/{i386 => x86}/boot/voyager.c |0
arch/x86/crypto/Makefile |5 +
.../crypto/Makefile => x86/crypto/Makefile_32} |4 +-
.../crypto/Makefile => x86/crypto/Makefile_64} |4 +-
arch/{i386 => x86}/crypto/aes-i586-asm.S |0
arch/{x86_64 => x86}/crypto/aes-x86_64-asm.S |0
arch/{i386/crypto/aes.c => x86/crypto/aes_32.c}|0
arch/{x86_64/crypto/aes.c => x86/crypto/aes_64.c} |0
arch/{i386 => x86}/crypto/twofish-i586-asm.S |0
arch/{x86_64 => x86}/crypto/twofish-x86_64-asm.S |0
.../crypto/twofish.c => x86/crypto/twofish_32.c} |0
.../crypto/twofish.c => x86/crypto/twofish_64.c} |0
arch/{i386/defconfig => x86/defconfig_32} |0
arch/{x86_64/defconfig => x86/defconfig_64}|0
Re: [RFC, Announce] Unified x86 architecture, arch/x86
* 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 +-
Makefile | 23 +-
arch/i386/Kconfig | 1275 +-
arch/i386/Makefile | 208 +--
arch/i386/kernel/early_printk.c|2 -
arch/i386/kernel/tsc_sync.c|1 -
arch/x86/Kconfig | 1919
arch/{i386 = x86}/Kconfig.cpu |0
arch/{i386 = x86}/Kconfig.debug | 50 +-
arch/x86/Kconfig_32| 1283 +
arch/{i386/Kconfig.debug = x86/Kconfig_32.debug} |0
arch/x86/Kconfig_64| 792
.../{x86_64/Kconfig.debug = x86/Kconfig_64.debug} |0
arch/x86/Makefile |5 +
arch/{i386 = x86}/Makefile.cpu|0
arch/x86/Makefile_32 | 163 ++
arch/x86/Makefile_64 | 128 ++
arch/{i386 = x86}/boot/.gitignore |0
arch/{i386 = x86}/boot/Makefile |6 +-
arch/{i386 = x86}/boot/a20.c |0
arch/{i386 = x86}/boot/apm.c |0
arch/{i386 = x86}/boot/bitops.h |0
arch/{i386 = x86}/boot/boot.h |0
arch/{i386 = x86}/boot/cmdline.c |0
arch/{i386 = x86}/boot/code16gcc.h|0
arch/{i386 = x86}/boot/compressed/.gitignore |0
arch/x86/boot/compressed/Makefile |5 +
.../Makefile = x86/boot/compressed/Makefile_32} |8 +-
.../Makefile = x86/boot/compressed/Makefile_64} |8 +-
.../head.S = x86/boot/compressed/head_32.S} |0
.../head.S = x86/boot/compressed/head_64.S} |0
.../misc.c = x86/boot/compressed/misc_32.c} |0
.../misc.c = x86/boot/compressed/misc_64.c} |0
arch/{i386 = x86}/boot/compressed/relocs.c|0
.../boot/compressed/vmlinux_32.lds}|0
.../boot/compressed/vmlinux_32.scr}|0
.../boot/compressed/vmlinux_64.lds}|0
.../boot/compressed/vmlinux_64.scr}|0
arch/{i386 = x86}/boot/copy.S |0
arch/{i386 = x86}/boot/cpu.c |0
arch/{i386 = x86}/boot/cpucheck.c |0
arch/{i386 = x86}/boot/edd.c |0
arch/{i386 = x86}/boot/header.S |0
arch/{i386 = x86}/boot/install.sh |0
arch/{i386 = x86}/boot/main.c |0
arch/{i386 = x86}/boot/mca.c |0
arch/{i386 = x86}/boot/memory.c |0
arch/{i386 = x86}/boot/mtools.conf.in |0
arch/{i386 = x86}/boot/pm.c |0
arch/{i386 = x86}/boot/pmjump.S |0
arch/{i386 = x86}/boot/printf.c |0
arch/x86/boot/setup.S |7 +
arch/{i386 = x86}/boot/setup.ld |0
arch/{i386 = x86}/boot/string.c |0
arch/{i386 = x86}/boot/tools/.gitignore |0
arch/{i386 = x86}/boot/tools/build.c |0
arch/{i386 = x86}/boot/tty.c |0
arch/{i386 = x86}/boot/version.c |0
arch/{i386 = x86}/boot/vesa.h |0
arch/{i386 = x86}/boot/video-bios.c |0
arch/{i386 = x86}/boot/video-vesa.c |0
arch/{i386 = x86}/boot/video-vga.c|0
arch/{i386 = x86}/boot/video.c|0
arch/{i386 = x86}/boot/video.h|0
arch/{i386 = x86}/boot/voyager.c |0
arch/x86/crypto/Makefile |5 +
.../crypto/Makefile = x86/crypto/Makefile_32} |4 +-
.../crypto/Makefile = x86/crypto/Makefile_64} |4 +-
arch/{i386 = x86}/crypto/aes-i586-asm.S |0
arch/{x86_64 = x86}/crypto/aes-x86_64-asm.S |0
arch/{i386/crypto/aes.c = x86/crypto/aes_32.c}|0
arch/{x86_64/crypto/aes.c = x86/crypto/aes_64.c} |0
arch/{i386 = x86}/crypto/twofish-i586-asm.S |0
arch/{x86_64 = x86}/crypto/twofish-x86_64-asm.S |0
.../crypto/twofish.c = x86/crypto/twofish_32.c} |0
.../crypto/twofish.c = x86/crypto/twofish_64.c} |0
arch/{i386/defconfig = x86/defconfig_32} |0
arch/{x86_64/defconfig = x86/defconfig_64}|0
arch/{x86_64 = x86}/ia32/Makefile |0
Re: [PATCH] Use descriptor's functions instead of inline assembly
* 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.
>
> Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
>
> diff --git a/arch/x86_64/kernel/head64.c b/arch/x86_64/kernel/head64.c
> index 6c34bdd..dde41d7 100644
> --- a/arch/x86_64/kernel/head64.c
> +++ b/arch/x86_64/kernel/head64.c
> @@ -70,7 +70,7 @@ void __init x86_64_start_kernel(char * real_mode_data)
>
> for (i = 0; i < IDT_ENTRIES; i++)
> set_intr_gate(i, early_idt_handler);
> - asm volatile("lidt %0" :: "m" (idt_descr));
> + load_idt((const struct desc_ptr *)_descr);
No need for extra casting
> early_printk("Kernel alive\n");
>
> diff --git a/arch/x86_64/kernel/reboot.c b/arch/x86_64/kernel/reboot.c
> index 7503068..7c50a12 100644
> --- a/arch/x86_64/kernel/reboot.c
> +++ b/arch/x86_64/kernel/reboot.c
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -132,7 +133,7 @@ void machine_emergency_restart(void)
> }
>
> case BOOT_TRIPLE:
> - __asm__ __volatile__("lidt (%0)": :"r" (_idt));
> + load_idt((const struct desc_ptr *)_idt);
same here, plus opportunity for cleanup
> __asm__ __volatile__("int3");
>
> reboot_type = BOOT_KBD;
> diff --git a/arch/x86_64/kernel/setup64.c b/arch/x86_64/kernel/setup64.c
> index 1200aaa..fef7290 100644
> --- a/arch/x86_64/kernel/setup64.c
> +++ b/arch/x86_64/kernel/setup64.c
> @@ -224,8 +224,8 @@ void __cpuinit cpu_init (void)
> memcpy(cpu_gdt(cpu), cpu_gdt_table, GDT_SIZE);
>
> cpu_gdt_descr[cpu].size = GDT_SIZE;
> - asm volatile("lgdt %0" :: "m" (cpu_gdt_descr[cpu]));
> - asm volatile("lidt %0" :: "m" (idt_descr));
> + load_gdt((const struct desc_ptr *)_gdt_descr[cpu]);
> + load_idt((const struct desc_ptr *)_descr);
same here
> memset(me->thread.tls_array, 0, GDT_ENTRY_TLS_ENTRIES * 8);
> syscall_init();
> diff --git a/arch/x86_64/kernel/suspend.c b/arch/x86_64/kernel/suspend.c
> index b39d478..ddedadf 100644
> --- a/arch/x86_64/kernel/suspend.c
> +++ b/arch/x86_64/kernel/suspend.c
> @@ -32,9 +32,9 @@ void __save_processor_state(struct saved_context *ctxt)
> /*
>* descriptor tables
>*/
> - asm volatile ("sgdt %0" : "=m" (ctxt->gdt_limit));
> - asm volatile ("sidt %0" : "=m" (ctxt->idt_limit));
> - asm volatile ("str %0" : "=m" (ctxt->tr));
> + store_gdt((struct desc_ptr *)>gdt_limit);
> + store_idt((struct desc_ptr *)>idt_limit);
same here, opportunity for cleanup
> + store_tr(ctxt->tr);
>
> /* XMM0..XMM15 should be handled by kernel_fpu_begin(). */
> /*
> @@ -91,8 +91,9 @@ void __restore_processor_state(struct saved_context *ctxt)
>* now restore the descriptor tables to their proper values
>* ltr is done i fix_processor_context().
>*/
> - asm volatile ("lgdt %0" :: "m" (ctxt->gdt_limit));
> - asm volatile ("lidt %0" :: "m" (ctxt->idt_limit));
> + load_gdt((const struct desc_ptr *)>gdt_limit);
> + load_idt((const struct desc_ptr *)>idt_limit);
> +
>
> /*
>* segment registers
> diff --git a/include/asm-x86_64/desc.h b/include/asm-x86_64/desc.h
> index ac991b5..f2b0a6f 100644
> --- a/include/asm-x86_64/desc.h
> +++ b/include/asm-x86_64/desc.h
> @@ -20,6 +20,15 @@ extern struct desc_struct cpu_gdt_table[GDT_ENTRIES];
> #define load_LDT_desc() asm volatile("lldt %w0"::"r" (GDT_ENTRY_LDT*8))
> #define clear_LDT() asm volatile("lldt %w0"::"r" (0))
>
> +static inline unsigned long __store_tr(void)
> +{
> + unsigned long tr;
> + asm volatile ("str %w0":"=r" (tr));
> + return tr;
> +}
native_store_tr (although I've no objection to just fixing the interface)
Index: linus-2.6/arch/x86_64/kernel/head64.c
===
--- linus-2.6.orig/arch/x86_64/kernel/head64.c
+++ linus-2.6/arch/x86_64/kernel/head64.c
@@ -70,7 +70,7 @@ void __init x86_64_start_kernel(char * r
for (i = 0; i < IDT_ENTRIES; i++)
set_intr_gate(i, early_idt_handler);
- load_idt((const struct desc_ptr *)_descr);
+ load_idt(_descr);
early_printk("Kernel alive\n");
Index: linus-2.6/arch/x86_64/kernel/reboot.c
===
--- linus-2.6.orig/arch/x86_64/kernel/reboot.c
+++ linus-2.6/arch/x86_64/kernel/reboot.c
@@ -24,7 +24,7 @@
void (*pm_power_off)(void);
EXPORT_SYMBOL(pm_power_off);
-static long no_idt[3];
+static struct desc_ptr no_idt;
static enum {
BOOT_TRIPLE = 't',
BOOT_KBD = 'k'
@@ -133,7 +133,7 @@ void
Re: [PATCH 2/3] i386: use x86_64's desc_def.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 rid of the duplicate definitions here, but then added new
> > > duplicates (GET_CONTENTS / WRITABLE). Can you stick them in desc.h?
> >
> > To be honest, I got sick of counting bits at this point, and didn't want
> > to introduce bugs.
> >
> > Here's the updated version of PATCH 1/3:
>
> And 2/3:
> ===
> i386: use x86_64's desc_def.h
plus this needed as well now
Index: linus-2.6/include/asm-i386/xen/hypercall.h
===
--- linus-2.6.orig/include/asm-i386/xen/hypercall.h
+++ linus-2.6/include/asm-i386/xen/hypercall.h
@@ -359,8 +359,8 @@ MULTI_update_descriptor(struct multicall
mcl->op = __HYPERVISOR_update_descriptor;
mcl->args[0] = maddr;
mcl->args[1] = maddr >> 32;
- mcl->args[2] = desc.a;
- mcl->args[3] = desc.b;
+ mcl->args[2] = desc.raw32.a;
+ mcl->args[3] = desc.raw32.b;
}
static inline void
Index: linus-2.6/drivers/lguest/interrupts_and_traps.c
===
--- linus-2.6.orig/drivers/lguest/interrupts_and_traps.c
+++ linus-2.6/drivers/lguest/interrupts_and_traps.c
@@ -103,9 +103,9 @@ void maybe_do_interrupt(struct lguest *l
}
idt = >idt[FIRST_EXTERNAL_VECTOR+irq];
- if (idt_present(idt->a, idt->b)) {
+ if (idt_present(idt->raw32.a, idt->raw32.b)) {
clear_bit(irq, lg->irqs_pending);
- set_guest_interrupt(lg, idt->a, idt->b, 0);
+ set_guest_interrupt(lg, idt->raw32.a, idt->raw32.b, 0);
}
}
@@ -116,7 +116,7 @@ static int has_err(unsigned int trap)
int deliver_trap(struct lguest *lg, unsigned int num)
{
- u32 lo = lg->idt[num].a, hi = lg->idt[num].b;
+ u32 lo = lg->idt[num].raw32.a, hi = lg->idt[num].raw32.b;
if (!idt_present(lo, hi))
return 0;
@@ -139,7 +139,7 @@ static int direct_trap(const struct lgue
return 0;
/* Interrupt gates (0xE) or not present (0x0) can't go direct. */
- return idt_type(trap->a, trap->b) == 0xF;
+ return idt_type(trap->raw32.a, trap->raw32.b) == 0xF;
}
void pin_stack_pages(struct lguest *lg)
@@ -170,15 +170,15 @@ static void set_trap(struct lguest *lg,
u8 type = idt_type(lo, hi);
if (!idt_present(lo, hi)) {
- trap->a = trap->b = 0;
+ trap->raw32.a = trap->raw32.b = 0;
return;
}
if (type != 0xE && type != 0xF)
kill_guest(lg, "bad IDT type %i", type);
- trap->a = ((__KERNEL_CS|GUEST_PL)<<16) | (lo&0x);
- trap->b = (hi&0xEF00);
+ trap->raw32.a = ((__KERNEL_CS|GUEST_PL)<<16) | (lo&0x);
+ trap->raw32.b = (hi&0xEF00);
}
void load_guest_idt_entry(struct lguest *lg, unsigned int num, u32 lo, u32 hi)
@@ -204,8 +204,8 @@ static void default_idt_entry(struct des
if (trap == LGUEST_TRAP_ENTRY)
flags |= (GUEST_PL << 13);
- idt->a = (LGUEST_CS<<16) | (handler&0x);
- idt->b = (handler&0x) | flags;
+ idt->raw32.a = (LGUEST_CS<<16) | (handler&0x);
+ idt->raw32.b = (handler&0x) | flags;
}
void setup_default_idt_entries(struct lguest_ro_state *state,
Index: linus-2.6/drivers/lguest/lg.h
===
--- linus-2.6.orig/drivers/lguest/lg.h
+++ linus-2.6/drivers/lguest/lg.h
@@ -44,8 +44,8 @@ void free_pagetables(void);
int init_pagetables(struct page **switcher_page, unsigned int pages);
/* Full 4G segment descriptors, suitable for CS and DS. */
-#define FULL_EXEC_SEGMENT ((struct desc_struct){0x, 0x00cf9b00})
-#define FULL_SEGMENT ((struct desc_struct){0x, 0x00cf9300})
+#define FULL_EXEC_SEGMENT ((struct desc_struct){ {0x00cf9b00ULL} })
+#define FULL_SEGMENT ((struct desc_struct){ {0x00cf9300ULL} })
struct lguest_dma_info
{
Index: linus-2.6/drivers/lguest/lguest.c
===
--- linus-2.6.orig/drivers/lguest/lguest.c
+++ linus-2.6/drivers/lguest/lguest.c
@@ -173,7 +173,7 @@ static void lguest_load_idt(const struct
struct desc_struct *idt = (void *)desc->address;
for (i = 0; i < (desc->size+1)/8; i++)
- hcall(LHCALL_LOAD_IDT_ENTRY, i, idt[i].a, idt[i].b);
+ hcall(LHCALL_LOAD_IDT_ENTRY, i, idt[i].raw32.a, idt[i].raw32.b);
}
static void lguest_load_gdt(const struct Xgt_desc_struct *desc)
Index: linus-2.6/drivers/lguest/segments.c
===
---
Re: [PATCH 3/3] i386: Replace struct Xgt_desc_struct with struct desc_ptr
* 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
+++ linus-2.6/drivers/lguest/lg.h
@@ -91,13 +91,13 @@ struct lguest_ro_state
{
/* Host information we need to restore when we switch back. */
u32 host_cr3;
- struct Xgt_desc_struct host_idt_desc;
- struct Xgt_desc_struct host_gdt_desc;
+ struct desc_ptr host_idt_desc;
+ struct desc_ptr host_gdt_desc;
u32 host_sp;
/* Fields which are used when guest is running. */
- struct Xgt_desc_struct guest_idt_desc;
- struct Xgt_desc_struct guest_gdt_desc;
+ struct desc_ptr guest_idt_desc;
+ struct desc_ptr guest_gdt_desc;
struct i386_hw_tss guest_tss;
struct desc_struct guest_idt[IDT_ENTRIES];
struct desc_struct guest_gdt[GDT_ENTRIES];
Index: linus-2.6/arch/i386/xen/enlighten.c
===
--- linus-2.6.orig/arch/i386/xen/enlighten.c
+++ linus-2.6/arch/i386/xen/enlighten.c
@@ -301,7 +301,7 @@ static void xen_set_ldt(const void *addr
xen_mc_issue(PARAVIRT_LAZY_CPU);
}
-static void xen_load_gdt(const struct Xgt_desc_struct *dtr)
+static void xen_load_gdt(const struct desc_ptr *dtr)
{
unsigned long *frames;
unsigned long va = dtr->address;
@@ -401,7 +401,7 @@ static int cvt_gate_to_trap(int vector,
}
/* Locations of each CPU's IDT */
-static DEFINE_PER_CPU(struct Xgt_desc_struct, idt_desc);
+static DEFINE_PER_CPU(struct desc_ptr, idt_desc);
/* Set an IDT entry. If the entry is part of the current IDT, then
also update Xen. */
@@ -433,7 +433,7 @@ static void xen_write_idt_entry(struct d
preempt_enable();
}
-static void xen_convert_trap_info(const struct Xgt_desc_struct *desc,
+static void xen_convert_trap_info(const struct desc_ptr *desc,
struct trap_info *traps)
{
unsigned in, out, count;
@@ -452,7 +452,7 @@ static void xen_convert_trap_info(const
void xen_copy_trap_info(struct trap_info *traps)
{
- const struct Xgt_desc_struct *desc = &__get_cpu_var(idt_desc);
+ const struct desc_ptr *desc = &__get_cpu_var(idt_desc);
xen_convert_trap_info(desc, traps);
}
@@ -460,7 +460,7 @@ void xen_copy_trap_info(struct trap_info
/* Load a new IDT into Xen. In principle this can be per-CPU, so we
hold a spinlock to protect the static traps[] array (static because
it avoids allocation, and saves stack space). */
-static void xen_load_idt(const struct Xgt_desc_struct *desc)
+static void xen_load_idt(const struct desc_ptr *desc)
{
static DEFINE_SPINLOCK(lock);
static struct trap_info traps[257];
Index: linus-2.6/drivers/lguest/lguest.c
===
--- linus-2.6.orig/drivers/lguest/lguest.c
+++ linus-2.6/drivers/lguest/lguest.c
@@ -167,7 +167,7 @@ static void lguest_write_idt_entry(struc
hcall(LHCALL_LOAD_IDT_ENTRY, entrynum, low, high);
}
-static void lguest_load_idt(const struct Xgt_desc_struct *desc)
+static void lguest_load_idt(const struct desc_ptr *desc)
{
unsigned int i;
struct desc_struct *idt = (void *)desc->address;
@@ -176,7 +176,7 @@ static void lguest_load_idt(const struct
hcall(LHCALL_LOAD_IDT_ENTRY, i, idt[i].raw32.a, idt[i].raw32.b);
}
-static void lguest_load_gdt(const struct Xgt_desc_struct *desc)
+static void lguest_load_gdt(const struct desc_ptr *desc)
{
BUG_ON((desc->size+1)/8 != GDT_ENTRIES);
hcall(LHCALL_LOAD_GDT, __pa(desc->address), GDT_ENTRIES, 0);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] i386: use x86_64's desc_def.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 rid of the duplicate definitions here, but then added new
duplicates (GET_CONTENTS / WRITABLE). Can you stick them in desc.h?
To be honest, I got sick of counting bits at this point, and didn't want
to introduce bugs.
Here's the updated version of PATCH 1/3:
And 2/3:
===
i386: use x86_64's desc_def.h
plus this needed as well now
Index: linus-2.6/include/asm-i386/xen/hypercall.h
===
--- linus-2.6.orig/include/asm-i386/xen/hypercall.h
+++ linus-2.6/include/asm-i386/xen/hypercall.h
@@ -359,8 +359,8 @@ MULTI_update_descriptor(struct multicall
mcl-op = __HYPERVISOR_update_descriptor;
mcl-args[0] = maddr;
mcl-args[1] = maddr 32;
- mcl-args[2] = desc.a;
- mcl-args[3] = desc.b;
+ mcl-args[2] = desc.raw32.a;
+ mcl-args[3] = desc.raw32.b;
}
static inline void
Index: linus-2.6/drivers/lguest/interrupts_and_traps.c
===
--- linus-2.6.orig/drivers/lguest/interrupts_and_traps.c
+++ linus-2.6/drivers/lguest/interrupts_and_traps.c
@@ -103,9 +103,9 @@ void maybe_do_interrupt(struct lguest *l
}
idt = lg-idt[FIRST_EXTERNAL_VECTOR+irq];
- if (idt_present(idt-a, idt-b)) {
+ if (idt_present(idt-raw32.a, idt-raw32.b)) {
clear_bit(irq, lg-irqs_pending);
- set_guest_interrupt(lg, idt-a, idt-b, 0);
+ set_guest_interrupt(lg, idt-raw32.a, idt-raw32.b, 0);
}
}
@@ -116,7 +116,7 @@ static int has_err(unsigned int trap)
int deliver_trap(struct lguest *lg, unsigned int num)
{
- u32 lo = lg-idt[num].a, hi = lg-idt[num].b;
+ u32 lo = lg-idt[num].raw32.a, hi = lg-idt[num].raw32.b;
if (!idt_present(lo, hi))
return 0;
@@ -139,7 +139,7 @@ static int direct_trap(const struct lgue
return 0;
/* Interrupt gates (0xE) or not present (0x0) can't go direct. */
- return idt_type(trap-a, trap-b) == 0xF;
+ return idt_type(trap-raw32.a, trap-raw32.b) == 0xF;
}
void pin_stack_pages(struct lguest *lg)
@@ -170,15 +170,15 @@ static void set_trap(struct lguest *lg,
u8 type = idt_type(lo, hi);
if (!idt_present(lo, hi)) {
- trap-a = trap-b = 0;
+ trap-raw32.a = trap-raw32.b = 0;
return;
}
if (type != 0xE type != 0xF)
kill_guest(lg, bad IDT type %i, type);
- trap-a = ((__KERNEL_CS|GUEST_PL)16) | (lo0x);
- trap-b = (hi0xEF00);
+ trap-raw32.a = ((__KERNEL_CS|GUEST_PL)16) | (lo0x);
+ trap-raw32.b = (hi0xEF00);
}
void load_guest_idt_entry(struct lguest *lg, unsigned int num, u32 lo, u32 hi)
@@ -204,8 +204,8 @@ static void default_idt_entry(struct des
if (trap == LGUEST_TRAP_ENTRY)
flags |= (GUEST_PL 13);
- idt-a = (LGUEST_CS16) | (handler0x);
- idt-b = (handler0x) | flags;
+ idt-raw32.a = (LGUEST_CS16) | (handler0x);
+ idt-raw32.b = (handler0x) | flags;
}
void setup_default_idt_entries(struct lguest_ro_state *state,
Index: linus-2.6/drivers/lguest/lg.h
===
--- linus-2.6.orig/drivers/lguest/lg.h
+++ linus-2.6/drivers/lguest/lg.h
@@ -44,8 +44,8 @@ void free_pagetables(void);
int init_pagetables(struct page **switcher_page, unsigned int pages);
/* Full 4G segment descriptors, suitable for CS and DS. */
-#define FULL_EXEC_SEGMENT ((struct desc_struct){0x, 0x00cf9b00})
-#define FULL_SEGMENT ((struct desc_struct){0x, 0x00cf9300})
+#define FULL_EXEC_SEGMENT ((struct desc_struct){ {0x00cf9b00ULL} })
+#define FULL_SEGMENT ((struct desc_struct){ {0x00cf9300ULL} })
struct lguest_dma_info
{
Index: linus-2.6/drivers/lguest/lguest.c
===
--- linus-2.6.orig/drivers/lguest/lguest.c
+++ linus-2.6/drivers/lguest/lguest.c
@@ -173,7 +173,7 @@ static void lguest_load_idt(const struct
struct desc_struct *idt = (void *)desc-address;
for (i = 0; i (desc-size+1)/8; i++)
- hcall(LHCALL_LOAD_IDT_ENTRY, i, idt[i].a, idt[i].b);
+ hcall(LHCALL_LOAD_IDT_ENTRY, i, idt[i].raw32.a, idt[i].raw32.b);
}
static void lguest_load_gdt(const struct Xgt_desc_struct *desc)
Index: linus-2.6/drivers/lguest/segments.c
===
--- linus-2.6.orig/drivers/lguest/segments.c
+++ linus-2.6/drivers/lguest/segments.c
@@ -3,12 +3,12 @@
static int
Re: [PATCH 3/3] i386: Replace struct Xgt_desc_struct with struct desc_ptr
* 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
+++ linus-2.6/drivers/lguest/lg.h
@@ -91,13 +91,13 @@ struct lguest_ro_state
{
/* Host information we need to restore when we switch back. */
u32 host_cr3;
- struct Xgt_desc_struct host_idt_desc;
- struct Xgt_desc_struct host_gdt_desc;
+ struct desc_ptr host_idt_desc;
+ struct desc_ptr host_gdt_desc;
u32 host_sp;
/* Fields which are used when guest is running. */
- struct Xgt_desc_struct guest_idt_desc;
- struct Xgt_desc_struct guest_gdt_desc;
+ struct desc_ptr guest_idt_desc;
+ struct desc_ptr guest_gdt_desc;
struct i386_hw_tss guest_tss;
struct desc_struct guest_idt[IDT_ENTRIES];
struct desc_struct guest_gdt[GDT_ENTRIES];
Index: linus-2.6/arch/i386/xen/enlighten.c
===
--- linus-2.6.orig/arch/i386/xen/enlighten.c
+++ linus-2.6/arch/i386/xen/enlighten.c
@@ -301,7 +301,7 @@ static void xen_set_ldt(const void *addr
xen_mc_issue(PARAVIRT_LAZY_CPU);
}
-static void xen_load_gdt(const struct Xgt_desc_struct *dtr)
+static void xen_load_gdt(const struct desc_ptr *dtr)
{
unsigned long *frames;
unsigned long va = dtr-address;
@@ -401,7 +401,7 @@ static int cvt_gate_to_trap(int vector,
}
/* Locations of each CPU's IDT */
-static DEFINE_PER_CPU(struct Xgt_desc_struct, idt_desc);
+static DEFINE_PER_CPU(struct desc_ptr, idt_desc);
/* Set an IDT entry. If the entry is part of the current IDT, then
also update Xen. */
@@ -433,7 +433,7 @@ static void xen_write_idt_entry(struct d
preempt_enable();
}
-static void xen_convert_trap_info(const struct Xgt_desc_struct *desc,
+static void xen_convert_trap_info(const struct desc_ptr *desc,
struct trap_info *traps)
{
unsigned in, out, count;
@@ -452,7 +452,7 @@ static void xen_convert_trap_info(const
void xen_copy_trap_info(struct trap_info *traps)
{
- const struct Xgt_desc_struct *desc = __get_cpu_var(idt_desc);
+ const struct desc_ptr *desc = __get_cpu_var(idt_desc);
xen_convert_trap_info(desc, traps);
}
@@ -460,7 +460,7 @@ void xen_copy_trap_info(struct trap_info
/* Load a new IDT into Xen. In principle this can be per-CPU, so we
hold a spinlock to protect the static traps[] array (static because
it avoids allocation, and saves stack space). */
-static void xen_load_idt(const struct Xgt_desc_struct *desc)
+static void xen_load_idt(const struct desc_ptr *desc)
{
static DEFINE_SPINLOCK(lock);
static struct trap_info traps[257];
Index: linus-2.6/drivers/lguest/lguest.c
===
--- linus-2.6.orig/drivers/lguest/lguest.c
+++ linus-2.6/drivers/lguest/lguest.c
@@ -167,7 +167,7 @@ static void lguest_write_idt_entry(struc
hcall(LHCALL_LOAD_IDT_ENTRY, entrynum, low, high);
}
-static void lguest_load_idt(const struct Xgt_desc_struct *desc)
+static void lguest_load_idt(const struct desc_ptr *desc)
{
unsigned int i;
struct desc_struct *idt = (void *)desc-address;
@@ -176,7 +176,7 @@ static void lguest_load_idt(const struct
hcall(LHCALL_LOAD_IDT_ENTRY, i, idt[i].raw32.a, idt[i].raw32.b);
}
-static void lguest_load_gdt(const struct Xgt_desc_struct *desc)
+static void lguest_load_gdt(const struct desc_ptr *desc)
{
BUG_ON((desc-size+1)/8 != GDT_ENTRIES);
hcall(LHCALL_LOAD_GDT, __pa(desc-address), GDT_ENTRIES, 0);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Use descriptor's functions instead of inline assembly
* 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.
Signed-off-by: Glauber de Oliveira Costa [EMAIL PROTECTED]
diff --git a/arch/x86_64/kernel/head64.c b/arch/x86_64/kernel/head64.c
index 6c34bdd..dde41d7 100644
--- a/arch/x86_64/kernel/head64.c
+++ b/arch/x86_64/kernel/head64.c
@@ -70,7 +70,7 @@ void __init x86_64_start_kernel(char * real_mode_data)
for (i = 0; i IDT_ENTRIES; i++)
set_intr_gate(i, early_idt_handler);
- asm volatile(lidt %0 :: m (idt_descr));
+ load_idt((const struct desc_ptr *)idt_descr);
No need for extra casting
early_printk(Kernel alive\n);
diff --git a/arch/x86_64/kernel/reboot.c b/arch/x86_64/kernel/reboot.c
index 7503068..7c50a12 100644
--- a/arch/x86_64/kernel/reboot.c
+++ b/arch/x86_64/kernel/reboot.c
@@ -11,6 +11,7 @@
#include linux/sched.h
#include asm/io.h
#include asm/delay.h
+#include asm/desc.h
#include asm/hw_irq.h
#include asm/system.h
#include asm/pgtable.h
@@ -132,7 +133,7 @@ void machine_emergency_restart(void)
}
case BOOT_TRIPLE:
- __asm__ __volatile__(lidt (%0): :r (no_idt));
+ load_idt((const struct desc_ptr *)no_idt);
same here, plus opportunity for cleanup
__asm__ __volatile__(int3);
reboot_type = BOOT_KBD;
diff --git a/arch/x86_64/kernel/setup64.c b/arch/x86_64/kernel/setup64.c
index 1200aaa..fef7290 100644
--- a/arch/x86_64/kernel/setup64.c
+++ b/arch/x86_64/kernel/setup64.c
@@ -224,8 +224,8 @@ void __cpuinit cpu_init (void)
memcpy(cpu_gdt(cpu), cpu_gdt_table, GDT_SIZE);
cpu_gdt_descr[cpu].size = GDT_SIZE;
- asm volatile(lgdt %0 :: m (cpu_gdt_descr[cpu]));
- asm volatile(lidt %0 :: m (idt_descr));
+ load_gdt((const struct desc_ptr *)cpu_gdt_descr[cpu]);
+ load_idt((const struct desc_ptr *)idt_descr);
same here
memset(me-thread.tls_array, 0, GDT_ENTRY_TLS_ENTRIES * 8);
syscall_init();
diff --git a/arch/x86_64/kernel/suspend.c b/arch/x86_64/kernel/suspend.c
index b39d478..ddedadf 100644
--- a/arch/x86_64/kernel/suspend.c
+++ b/arch/x86_64/kernel/suspend.c
@@ -32,9 +32,9 @@ void __save_processor_state(struct saved_context *ctxt)
/*
* descriptor tables
*/
- asm volatile (sgdt %0 : =m (ctxt-gdt_limit));
- asm volatile (sidt %0 : =m (ctxt-idt_limit));
- asm volatile (str %0 : =m (ctxt-tr));
+ store_gdt((struct desc_ptr *)ctxt-gdt_limit);
+ store_idt((struct desc_ptr *)ctxt-idt_limit);
same here, opportunity for cleanup
+ store_tr(ctxt-tr);
/* XMM0..XMM15 should be handled by kernel_fpu_begin(). */
/*
@@ -91,8 +91,9 @@ void __restore_processor_state(struct saved_context *ctxt)
* now restore the descriptor tables to their proper values
* ltr is done i fix_processor_context().
*/
- asm volatile (lgdt %0 :: m (ctxt-gdt_limit));
- asm volatile (lidt %0 :: m (ctxt-idt_limit));
+ load_gdt((const struct desc_ptr *)ctxt-gdt_limit);
+ load_idt((const struct desc_ptr *)ctxt-idt_limit);
+
/*
* segment registers
diff --git a/include/asm-x86_64/desc.h b/include/asm-x86_64/desc.h
index ac991b5..f2b0a6f 100644
--- a/include/asm-x86_64/desc.h
+++ b/include/asm-x86_64/desc.h
@@ -20,6 +20,15 @@ extern struct desc_struct cpu_gdt_table[GDT_ENTRIES];
#define load_LDT_desc() asm volatile(lldt %w0::r (GDT_ENTRY_LDT*8))
#define clear_LDT() asm volatile(lldt %w0::r (0))
+static inline unsigned long __store_tr(void)
+{
+ unsigned long tr;
+ asm volatile (str %w0:=r (tr));
+ return tr;
+}
native_store_tr (although I've no objection to just fixing the interface)
Index: linus-2.6/arch/x86_64/kernel/head64.c
===
--- linus-2.6.orig/arch/x86_64/kernel/head64.c
+++ linus-2.6/arch/x86_64/kernel/head64.c
@@ -70,7 +70,7 @@ void __init x86_64_start_kernel(char * r
for (i = 0; i IDT_ENTRIES; i++)
set_intr_gate(i, early_idt_handler);
- load_idt((const struct desc_ptr *)idt_descr);
+ load_idt(idt_descr);
early_printk(Kernel alive\n);
Index: linus-2.6/arch/x86_64/kernel/reboot.c
===
--- linus-2.6.orig/arch/x86_64/kernel/reboot.c
+++ linus-2.6/arch/x86_64/kernel/reboot.c
@@ -24,7 +24,7 @@
void (*pm_power_off)(void);
EXPORT_SYMBOL(pm_power_off);
-static long no_idt[3];
+static struct desc_ptr no_idt;
static enum {
BOOT_TRIPLE = 't',
BOOT_KBD = 'k'
@@ -133,7 +133,7 @@ void machine_emergency_restart(void)
}
Re: [PATCH try #3] security: Convert LSM into a static interface
* 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. Yes, it does. I have measured it as have others (esp. after Kurt Garloff pointed out issues on ia64). thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #3] security: Convert LSM into a static interface
* 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. Yes, it does. I have measured it as have others (esp. after Kurt Garloff pointed out issues on ia64). thanks, -chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
